Evolved Code vs Enterprise Code

Once upon a time, Adrian Thompson accidentally created a magical artifact. He used a genetic algorithm to evolve a FPGA circuit that would distinguish between signals of two frequencies. The winning specimen was pretty unlikely: it worked on that chip only, and only at certain temperatures. It contained circuits that were not connected to the others, but when he turned those off the damned thing stopped working. The neighboring gates depended on that extra bit of inductance, which varied with a slight flaw in another gate... maybe. No one really knows.

Once upon a time, a small group of hackers evolved a piece of software. They focused so much on doing more with less that they themselves became crucial parts of the implementation: Leo took over ops because he stayed late to avoid traffic anyway. These support emails routed to Bianca because she spoke Spanish and Portuguese. Tatiana had a nicer touch with angry customers. Carlos had the pager because he's good at troubleshooting. Tom made the changes to the template parser because Tom's the genius who wrote it. The bug tracking system was a whiteboard. Every little detail seemed to depend on some idiosyncrasy of the people or their environment. It worked -- somehow. Every startup is a freak accident.

This is why I think Jaron Lanier's bomb-throwing about closed- versus open-source is off-target. When you're talking about the potential for "radical creativity" in a program, it doesn't matter how many people are allowed to read the source code, but how many are required to understand it. Having too many junior hackers on your source tree is just as bad as too many customers pestering you about compatibility.

The fundamental difference between the first two systems and the ones that come out of large organizations is that there was no difference between design and implementation. Enterprise code is designed, vetted, reviewed, implemented, deployed, life-cycled, etc. The purpose is to have no irreplaceable parts. On the other hand, the magic chip and the startup were evolved as fast as possible in a way that could never be exactly repeated.

A funny thing: when an enterprizey programmer and an alpha-hacker look at each other's code, the same thought occurs for different reasons: "How do they get away with this crap?"

The documentation is the code, alpha-hackers say. Don't you see that you're writing your programs in PowerPoint? The process gurus grumble darkly about heroics, maintainability, knowledge transfer, bus accidents. The enterprizey people regard design as something that must be as separate as possible from the expression-as-code. How else can it be maintained by anyone? Take away Tom and the thing no longer works. True, but if enterprizey was always better, BigCo wouldn't get their lunch eaten by wittle bitty startups.

This schism is most sharp when a big company eats a little one. Most startup acquisitions play out like a spider dissecting a fly: gruesomely impersonal and tedious. You just can't get over the mental image of that fat spider pick pick picking away at a violated husk. Yahoo's epic rewrite of RTML, its painful digestion of my company's system, and that poor bastard trying to understand his magical chip are all the same phenomenon.

There are bits that work only there & then, bits that may be impossible for an outsider to grok completely, bits that even the same people would do differently now.