Forgot your password?

Comment: Bacteria evolve faster... (Score 1) 174

by micromuncher (#32339656) Attached to: Synthetic Genome Drives Bacterial Cell

Students of genetics know that organisms with short life spans and simpler structures evolve much quicker that complex organisms.

A while back I had an idea to modify saccharomyces cerevisiae to include code for generating ligninase, xylanase, and cellulase. This would allow me to brew alcohol from wood etc. Presently the enzymes are harvested from aspergillus niger. Production and recovery are expensive.

So in comes a brewing bacteria that can "liquify wood." Wait. What if this bacteria were released into the environment in an uncontrolled fasion? What if it mutates? Wouldn't the result be catastrophic?

Comment: evil bob (Score 1) 191

by micromuncher (#31660488) Attached to: 15 Years of Microsoft Bob

Bob, clippy, and any other gadget that imposes its will upon you by default is a bad idea. People hate being told what to do, especially when something grabs UI focus from you and makes a non-modal process a modal one. Rule No. 1 of UI design is let the user focus on the task. Distracting the user... what were they thinking? I have years of pent up Clippy hatred because my Office technology is stuck at 97 and 2000 (by choice.) First thing I always get to do is try and recall how to turn them off. BOB IS ABOMINATION! Please let it die. Take WGA next.

Comment: Re:Selling horse that doesn't look too good (Score 1) 483

by micromuncher (#31077074) Attached to: How Do You Accurately Estimate Programming Time?

I'm very happy to hear it. Once upon a time I worked for a company that kept metrics on all its projects, and we (developers) used these metrics to validate our time estimates. We didn't measure current projects in % done; we measured by function point achieved. Sounds similar to what you mention. It was one of the most stress free times in my life, as they also had effective change management. These things are counter to the manifesto.

Comment: Selling horse that doesn't look too good (Score 1) 483

by micromuncher (#31076330) Attached to: How Do You Accurately Estimate Programming Time?

Some would recognize this as farmer speak for selling a blind horse, and after RTFM, where refactoring and work and revising guesses, the article called "Unskilled and Unaware" comes to mind. This article's basic premise is that people who are clueless tend to overestimate their ability.

In the old days, and with most engineering disciplines, costing is a quantified, factored skill. It is not an art. People with a great deal of experience, or whom have access to metrics, can cost building billion dollar chemical plants with reasonable error rates. It all comes down to experience, or metrics in another form.

First, you record how long it takes you to do something, and how complex it was, and how much risk there was. This knowledge can be used and applied to even unrelated projects. The biggest excuse I hear in software development is that we can't cost this because we haven't done it before. Bullshit. Remember design patterns? Someone has done it before. And it doesn't take much to figure out that something you are doing is either highly complex (and arguably requiring decomposition), or highly risky, and then cost it appropriately.

Then for those high risk items, apply a strategy like rapid prototyping, or spiral software (risk based) development practices.

Bullshit to the quality vs functionality argument too. The triangle of cost vs quality vs time or function does not take into account any of the elements for succesful project delivery, like experienced management, experienced leads, a positive working environment (read no asshole driven development), and people that actually think management is mo betta than leadership.

Rant off.

Comment: backward-a55 (Score 1) 301

by micromuncher (#30034542) Attached to: Reporting To Executives

Your executive (or usually the administrative secretaries) should communicate to you what they want. If they are not giving you an indication of the metrics they want, and they're leaving it to you, then you have the danger of boring them with useless and irrelevant information. Not repeating the 30k feet, brief, don't use IT speak comments; you likely want to engage someone close to them to figure out what metrics you gather, or can gather, and which are actually meaningful from the BI view. Oddly, information by itself is useless. Let me explain... I work for big oil/gas company (doing corporate reporting). One thing I provide is spill reports. They use this to scorecard divisions (for bonuses). But the information itself isn't very useful, because it doesn't say what products are spilled (specifically sometimes huge numbers come out re fresh water spills, and these are reportable to govt., but not as dangerous as sour gas...). The divisional guys get really annoyed because they're compared to previous years (so its spilled volume over time), and they really want me to speciate by operation or commodity, but I can't because the executive committee in charge doesn't care. They want ONE line item for an overall metric in one area of the business. So to reiterate, its really important to talk with them or someone close to them to figure out what is useful and what the "destination" is. Process improvement? Health check? Benefits/bonuses? Lots of categories to chose from.

Comment: StarTrekify my Life (Score 1) 899

by micromuncher (#29417005) Attached to: How To Make Science Popular Again?

I would like to have...
1) a cell phone that looks like a TOS communicator (one vaporphone was the Sona Mobile themed phone)
2) a micro-lab that looks like a TOS tricorder (hell, I'd be happy with GPS, temperature, and humidity sensors in a stylish box)
3) a laser pointer that looks like a TOS phaser (that would absolutely get attention in meetings)

Cool and useful science toys.

Comment: Formal proof? (Score 1) 517

by micromuncher (#29054403) Attached to: World's First Formally-Proven OS Kernel

Wow. How can you prove something like this... I know mathematical induction and various finite automata tests were used in my old school days to prove software worked... but something as complicated as this.

In any event, an inductive hypothesis in software is tripe. Unless you can formally describe all states, you usually have an unbounded problem, and people test (and prove) positive case. There are just way too many states.

Just like Bjarne said Proof by analogy is fraud... and induction is akin to analogy.

Do not use the blue keys on this terminal.