Software Longevity and Your Home Renovation

Engineering process has long been a fundamental part of countless industries. The automobile, airplane, and architectural industries are but a few. If it weren't, we wouldn't be flying airplanes to literally save our lives. The engineering process in the still-emerging field of software and systems development has yet to mature. But software is different from those "physical" disciplines, right? It can be easily changed; it's soft, malleable.

Except that it really isn't. Sure, its easy to change "Hello World!" to say "Hello World, how are you ?" But the more complex a system is, the longer it takes to modify. It's sort of like renovating a house; it's usually prohibitive to tear your house down and rebuild a new one, yet much of the cost of just renovating a portion of it can be attributed to working within the confines and limitations of the existing structure. If you really want to experience that soaring cost "high", just try to move plumbing :) Not to mention, you often have to live in it while the work is being done.

It's usually prohibitive to tear your house down and rebuild a new one, yet much of the cost of just renovating a portion of it can be attributed to working within the confines and limitations of the existing structure.

There's no physical mess (and hopefully no loud noise) with software renovation. That is, unless you count coffee stains, network cable, or the stereotypically obligatory pizza boxes. But in terms of person-hours, "renovating" complex software can take time analogous to renovations of a building. This cost is increased dramatically if software is not designed or built with longevity in mind.

Take refactoring, for example. Avoiding a refactor of code might be expedient in the short term, but over the long haul is more expensive. When new functionality is tacked on and must work with the old (which may itself have been tacked on) the system can become unnecessarily bloated and more difficult to change, with each new addition requiring reconciliation with an increasingly brittle code base. It's not a linear relationship either; things gets increasingly worse the larger a system gets.

Think of just shoving stuff into your kitchen fridge without rearranging or throwing out what's already there. Pretty soon you'll have a messy heap of food, with each new addition taking longer and longer to find a place for. There may even be old "food" growing in there that it has become difficult to even see.

Or think of a large tree. A software system has a life, just as a tree does. It grows roots and takes "hardened" form, draws resources, and provides benefit to others just like a tree. Its grown form serves a certain purpose, and as it grows, its particular form "hardens". It's easy to transplant a sapling, but once it reaches a certain size, it requires quite a bit more effort. The tree's roots grow in all directions, and it evolves to sustain all sorts of life. It may be very hard to move it to a location with proper sunlight or straighten it up if the trunk grows crooked.

You can't really stick one tree onto another, change its shape, or make arbitrary holes in it: it has a structure based on its purpose. The fact that software can be changed by typing code tends to obscure that reality; sure you can change a computer program, but the practical reality in complex systems is more like renovating a building than editing a paragraph of prose.

The same goes for software testing. The more complex the system, the more likely that abridged testing in service of lowering costs in the short term will cause much larger downtime costs as the system takes root and grows within a company's culture. Curtailed testing of a complex system means you'll find more bugs in the field, which again takes longer to fix on an ad-hoc basis than robust, up-front tests. Problems in the field can actually be mildly inconvenient and a bit costly; just ask British Petroleum.

You can't really stick one tree onto another, change its shape, or make arbitrary holes in it: it has a structure based on its purpose. The fact that software can be changed by typing code tends to obscure that reality.

If you prefer a software simile, the granddaddy of them all might be Microsoft's DOS / Windows / Windows3.1 / Win95 / Win98 / Win2K / WinME / WinCE / WinXP / Vista / Windows 7. That's a lot of replacement windows. If you think much of Microsoft's problems with blue screens, bugs, and user frustration over the years is not due to new code awkwardly trying to interact with and preserve the old, or corporate pressure to ship a new product by a certain date, I have an 80286 laptop running Vista in my office I'd like to sell you. Actually just come and take it. Please.

How many person hours were spent dealing with myriad issues on Windows over the years ? What Redmond saved in terms of testing, office workers everywhere lost many, many times over. But then again, let's generously say they shaved as much as $100 off the retail price of the OS by expediting the release. Given what employee overhead costs are per hour, that $100 doesn't really seem worth it. Or perhaps getting that latest version of Windows six months earlier was truly mission-critical?

Now consider the various flavors of Unix. Stable, reliable, relatively bug and virus-free over many years, Unix had time to evolve within the labs of industry and academia. Code written for a Unix machine 10 years ago will still run on a Unix OS today (and often vice-versa). It's even genetic code for the OS on your desktop or laptop, unless maybe you're using vacuum tubes. So it goes with evolution. Amazingly, 30 years after its inception, it is the software foundation of every new Apple computer today. That's in part because Unix was given a good birth. Its developers paid attention to design, and allowed it to grow and evolve with longevity in mind, and each small piece was tested by thousands and thousands of users. Veterans of the industry have traditionally considered Unix as a stalwart marvel of engineering. Windows? Not so much.

All this is more than just finicky software engineers on a pilgrimage of purity. It could easily be the difference between your enterprise system costing you more than it saves you. It's worth nurturing the tree's growth consistently and properly along the way; It would be a shame to have to cut it down.

  1. So true – the software development workbench is so abstract that it seems to the layperson that it should be so easy to change. If you employ continuous refactoring, changes are made easier, but there is no concrete analogue for “refactoring” in other engineering disciplines – makes it difficult to explain to the non-technical customer.

    Jeremy Chan
    Jun 30th, 2010
  2. It is hard to find engineering analogues. Since software has to do with information for productivity, it might be thought of in terms of other forms of organizing people and information. Maybe refactoring a large system can be imagined like rearranging or optimizing a physical network like Fedex delivery or the Walmart supply chain. Lots of moving parts and protocols to consider.

    Chris Chan
    Chris Chan
    Jul 1st, 2010

Add a comment

Comment feed
The better to greet you with
No one will ever see this
Your pride and joy
The reason this comment form exists

The crew behind ASOT

We're a team of interactive, software, and business intelligence experts skilled in the design, construction, and management of online enterprise systems.

Visit The Jonah Group site

Get in touch with us