Living Software

Let’s imagine a family home, with parents and a number of small children. The house is almost never empty, there is always something happening. Family members are cleaning the house, fetching groceries and maintaining the house. If they weren’t doing this, the house would deteriorate and become unlivable over time. In some sense, you can say that the house is alive.

Now let’s imagine a company in an office building. The company is serving its customers, and suppliers are delivering goods. Employees come to do their work. The building is cleaned and maintained. If that wouldn’t happen, the company would not succeed. In the same sense sense, you could say that the office building is alive.

Finally, let’s consider some software product that is sold to customers. There are always bugs to be fixed and customer requests. New opportunities and threats require changes to the software product. Developers work to improve the software. Technology changes require the software to keep up. You can see the product change over time, and the product has probably changed a lot when compared to a few years ago. If that wouldn’t happen, the product would wither away. In the same sense as the family home and office building, the software product can be said to be alive.

This fact that the software can be considered alive has some consequences that I want to explore in this post.

The product must be available

A very important aspect from a software product is that it must be available. This availability reaches beyond having a setup program for download: you need to actively support it and be able to release bug fixes quickly. Users simply won’t accept software that is not maintained.

Perhaps the best way to make this clear is to consider the opposite: not being able to release changes is a threat to the company. The world changes; being unable to keep up means that the company falls behind and loses market share. I don’t know about you, but I basically don’t consider to use a new program if its latest release was more than two years ago.

This means that you cannot take a break of more than a few months (context dependent) in delivering added value.

Keep the product from rotting away

Even when you provide a regular stream of bug fixes and new features, it is still possible that your product becomes less and less usable. This happens because of software rot: the fact that the product does not adapt to changes in the environment. Even the best MS-DOS programs have serious difficulty running on current Windows computers. Web sites written in Flash have stopped working, because the technology is not supported anymore.

No big rewrite in the sky

Sooner or later, the code becomes more and more messed up. New technologies are introduced and are much-promising, yet the technologies they replace never phase out, because that would cost too much time. So you end up supporting two versions of each technique, so working with the code base becomes more and more complex.

When this continues, sooner or later some tipping point is reached, where more and more effort is required for fewer and fewer results. Obscure bugs accumulate, and fixing them becomes more and more difficult. Not breaking things becomes a big concern and most new features will require a major effort. Frustration amounts. And sooner or later, someone proposes: “This will never work out! The code is unmaintainable. Let’s rewrite the code all over again!”.

As sensible as the proposal sounds, it is a dangerous decision. Since the software is alive, you cannot stop supporting the old version while developing the new one. Customers are using the legacy version and require fixes; they also request new features. New customers are buying the legacy software while the big rewrite is not production ready. Meanwhile, the team that develops the rewrite has to keep up with the old version: any new feature in the old version must also be implemented in the new version. Doing a complete rewrite also has the risk of missing features that are critical to customers. And would the existing customers have an easy time switching to the brand new version? Exactly because the version is brand new, it is likely to have many issues.

Incremental improvement

When you agree that software is alive and that delivered software provides business value, it is a serious risk to kill it. Just don’t do that. Sure, it is possible to do this for some utility that you can set up in a month or so. Or for rewriting a component when it is not too big. But rewriting a complete software product that encompasses years of work is almost always a certain mistake.

There is however another possibility: that of the incremental improvement. Software that is alive can be improved incrementally. By refactoring, you can separate out responsibilities and into their own well-defined modules. Then it is possible to replace such modules, or combine them to provide new features.

Is it always possible to make a transformation like this with incremental steps? I’m convinced that it is possible. I have yet to see a situation where incremental change cannot be done. There is always some starting point where simple refactoring is possible. On the opposite side, I’ve seen big rewrites fail more than once.