On Evolutionary Software Design and Helicopters

Airplanes are Safer than Helicopters

When I was in the military, we joked about jumping out of perfectly good airplanes.  Ironically, everyone seemed to agree that it was safer to jump from a helicopter than to ride in one.  I finally heard from an old NCO the best explanation for what we all knew instinctively.

Airplanes are reliable, elegant machines.  Helicopters are the sum of 50,000 parts flying in tight formation.

Thus was seeded my ultimate theory on the result of evolution on major software systems.  When a simple software system is instituted to solve a specific problem, it is a clean little airplane.  And then we tag on an extra responsibility to the application.  And then another developer adds a dependency through some data layer you didn’t know was there.  And then someone else writes a command line util that massages the data for use in yet another system, but this has a dependency on step A.  And then… 

Viola!  You are now riding in a helicopter.

Jump Out

People on my team have heard this analogy from me before, and we are able to identify several legacy helicopter systems.  Why then do we not simply refactor to airplane status?  Well, because we are working on other things.  These helicopter systems define our technical debt and often that technical debt must be abandoned to pressures of new development.  After all, we don’t decide what to build, just how to build it.

The thing is, helicopters usually get the job done.  They can carry a big load, but when they crash it can be hell getting them in the air again.  It is very easy for the business folks in your organization to get to relying on these helicopters and want to trot them out to solve every problem.  We even do it ourselves as developers.

“Well, if I use the data from over there and pass it through the XSLT engine Frank made last week and tie that to the queuing doohickey, it may just work.”

So what’s the answer?  A fleet of little airplanes with pluggable parts.  Make little applications with the same engines in them.  Componentize your engines, the wings, and fuselage.  Paint them uniquely and slap on different performance parts, but make the controls similar so pilots can fly most of the machines without retraining.

One could even say that an airplane factory could be in order, but we’ll save that for a different discussion.

Enough Already

Although I have probably stretched this metaphor to it’s breaking limit, I bet you get the point.  Evolutionary design is design, not uncoordinated developers that hack on a system until it has so many interdependencies that you must let it crash in order to get permission to build a new aircraft.  Keeping your airplane simple while making it more capable is an exercise in professional discipline. 

To some I may seem to be rambling, but to a great many of us I bet these are words felt close to the heart.  The moment you learn that team Foo on the other side of the company has tapped your data, shut it down.  Require a service layer interaction with them or something, but keep the abstraction level high.  Help them solve their problem before they ruin you.

Helicopters are cool, but they are far more dangerous than a simple glider.