Building sustainable software

Software sustainability can mean a few things. It may refer to the (energy) footprint of software when it’s being used. Software may indeed be efficiently or less efficiently coded. The differences can actually be quite substantial, especially in high volume transaction systems. It’s not something most programmers and architects are very aware of, and as a result, looking at this may very well produce significant energy savings. Although this is a very interesting topic, I’d like to focus on another possible meaning of software sustainability.

Let me try to make a comparison. A century ago, furniture would typically last a lifetime. Clothes would be worn for several years and then mended for an extended life. Today, however, much of our furniture needs to be treated carefully to prevent it from falling apart (especially after you’ve moved house and reassembled it). Similarly, clothes are meant just for the season (meaning one season). Many clothes are simply thrown away when fashion changes, and it changes quickly.

In this world, software is developed as a dispensable item, much like most things are developed to look nice for a few years, only to then be replaced. This is great for economy. At least for the economy of today.

But software isn’t like the trousers you throw away; it’s more like the furniture you keep for a lifetime. Trouble is, changes are frequently made to the organization. Business processes also often change. In furniture terms, this means you’re dismantling your IKEA wardrobe several times, transporting it, then rebuilding it in your new house where it requires a new door, a slightly smaller drawer and a built-in mirror. Every time you move, your lovely wardrobe is becoming less and less attractive. Problem is, all your clothes fit so perfectly inside, so you simply cannot buy a new one. In software terms, your data and processes are so in tune with your software that you simply cannot replace it with standard software. Your modest collection of books started with a basic Billy IKEA bookshelf, but after many moves and ambitious investments, it’s now the size of the New York Public Library. This is what’s happening in the real world (with software, that is, not your book collection).

In an agile world, we cannot start designing for the New York Public Library when we only have a few books to store. But at the same time, we can’t only design for the next sprint, either. If you do this, you’ll end up owning a library the size of New York’s with a bunch of Billies stacked on top of each other (or worse, 10 different brands of bookshelves varying in size and quality). We need to find the balance between agile speed and a future-proof architecture.

The way to do this is to continuously monitor your architecture and regularly re-evaluate. I discussed the Concorde moment in a previous blog; just remember that sometimes it’s necessary to take a step back to enable progress. Additionally, we also have to monitor for technical debt at the code level, the architectural level and the portfolio level. It can be done, but only when you realize that software isn’t just another dispensable item. Enterprise software, especially, has the tendency to live a lot longer than you might think.