Wednesday, August 12, 2009

A flag for the Nerd Republic

When we are ultimately forced to leave the earth in the hands of the robot overlords, I propose this flag for our future Nerd Republic. ;-)

Friday, August 7, 2009

Thinking like a chemist

Photo from flickr user zcreem

Suppose you were asked to mass produce a toy train car -- four little wheels connected to a small wooden chasis. Being an inhabitant of the 21st century you'd know exactly what to do: build an assembly line. After some tinkering you'd end up with some sort of jig that held the body into place and attached the wheels in a nice predictable fashion so that it could be repeated rapidly. Henry Ford would be proud of you.

But what if the wheels of the car were as small as atoms and the chassis a single molecule? Then how would you do it?

Such molecular assembly has been done for a long time, it's called chemistry. But chemists don't think about the assembly problem the way Henry Ford did. Their approach is fundamentally different.

A chemist would build the molecular toy car by putting four bazillion copies of the wheels into a bag full of water with a bazllion copies of the chassis and then they would shake the bag intensely assuring that some fraction, perhaps a minuscule portion of the original, would assemble themselves *by accident* into the toy car.

A chemist would then come up with a way to separate the fully assembled cars from all the left over parts that failed to assemble -- perhaps the vast majority of the pieces. For example, the chemist might dump the contents of the bag out over a pine tree. The un-assembled pieces, being smaller than the fully assembled pieces, might fall through the branches more easily while the the larger assembled pieces would be more likely to snag a branch and get stuck on the way down. As a result, the top branches of the tree would be more likely to hold the desired product. Then a chemist would snip off the top half of the tree and shake out the contents and repeat the process, knowing that for each repetition they have purified the sample a little bit. Having never even laid eyes on the target, they would declare that their end product was, say, 99% pure.

Seems absurd? It is. But it's also incredibly clever -- it permits the manipulation of atomic scale things by exploiting the fact that you are much, much larger than they are and can therefore easily move around quintillions of molecules inside of a "bag" no bigger than a drop of water. As a filter they'd use something like gelatin which at the molecular scale is a lot like the pine tree -- a big furry mess of interconnecting obstacles that would let some things pass though easily while inhibiting the movement of other things. As hard as it is to believe, this technique is accurate enough to allow separation by incredibly tiny differences in mass. Below is a picture of an actual gel, the light pink parts are the molecular batches (in this case DNA) that have been pulled through the gel which is the purple background. You can make out six tracks in this gel which is six different runs.

photo from wikicommons Gel_electrophoresis_2.jpg

Below is a picture of someone loading a gel. You can make out 10 "lanes" they are loading for their experiment. Into each lane they are placing a tiny drop of water using a pipette which is just a fancy eye-dropper. Each drop they are inserting into the gel might contain billions upon billions of the molecule of interest.

Photo from flikr user rocksee

Software prototypes

(Images adapted from flickr users Duke TIP and Patrick Beeson)

One way in which software engineering differs from other engineering disciplines is that in software the prototype is often confused with the real thing.

Nobody looks upon a prototype 1/50th scale model of a bridge and says "Looks done, let's drive trucks across it now." Yet in software development such sentiment is commonplace -- "Looks like it's working, all we have to do is clean up the bugs and ship it!"

If this were merely a misunderstanding between the programmers and the business-types it would be understandable, but the unfortunate fact is that it's often the programmers themselves who believe this. This attitude of hack-and-patch contributes to the general lack of quality of software compared to other engineering disciplines and this is compounded by the perceived low-cost of failure. Structural engineers don't say to themselves: "If it doesn't work we'll just patch it in the field." Electrical engineers don't say: "Ahh, sort of works... we'll upgrade it after tape-out." It has never occurred to a mechanical engineer that they could hide their lack of quality control by creating an automatic update system that secretly updates their wares behind their customer's backs.

For software engineering to be done right -- like in every other creative discipline -- time and space have to be allocated for building *disposable* prototypes. There is no progress without failure, but you don't have to subject your customers to your failures either.