Software - It’s not what you think it is - Part 4

In the previous post of this blog series we discussed the greenfield fallacy and its consequences. In this post we will discuss the next misconception, the value preservation dilemma and its consequences. Let us get started.

The value preservation dilemma

Many misconceptions regarding software stem from comparisons with physical products like, e.g., cars or houses. We already discussed the assembly line fallacy in the first post of this series. The value preservation dilemma also has its roots in these broken comparisons.

The core of the dilemma is that most people do not realize that software needs to be changed continually to preserve its value. Meir Lehman already 1980 pointed out in his great paper “Programs, life cycles, and laws of software evolution”, that all successful systems need to be adapted continuously to respond to the ever-changing needs of their environment. ¹

Software must be changed to preserve its value

This is very different from physical goods. E.g., we would never change a sports car into a family car into a pick-up into a truck into a cargo air craft into a cargo ship over time because of changing needs and demands. We would sell the old vehicle and buy a new one that was explicitly designed and built for the changed need. In software, this is different. We continuously modify the existing software to adapt to our changing needs and demands.

This does not only mean the software equivalent of a race car might turn into a cargo ship over time. It also means we often see mixtures of requirements implemented in software, we would never see in the physical world. E.g., in software we see cargo ships powered by jet engines connected to wings attached to the ship. The steering wheel and transmission are still from the sports car and for some meanwhile forgotten reasons you still need to be able to attach child safety seats all across the cargo holds.

While this may sound ridiculous at first glance, this is still a very moderate illustration of how software typically looks a few years after its initial release. Usually, it is a lot more complex and much harder to understand. The only reason, most people are not aware of it is the fact that software is invisible, another dilemma we will discuss in the next post of this series.

Software is a unique “material”

While the aforementioned analogy with physical transport vehicles may sound ridiculous, there may be very valid business reasons to change the software in such ways. There may be good reasons to turn the software from an airplane into a cargo ship over time. There may be good reasons to turn the software from a dog kennel into a skyscraper over time. One of the great properties of software is that it allows for such changes. Of course, if applied unchecked this malleability may also turn into a curse as we will see in the next post of this series.

As we can see, software is a quite unique “material”. Most other products and materials cannot continuously adapt to ever-changing needs of the environment. They were created for a pre-defined purpose and as long as they fit the needs and demands of the environment, they are useful. As soon as they do no longer fit the needs and demands of the environment, they become useless.

Software is different. It allows for continuous adaptation, even to a point where its original purpose does no longer exist in the code and it transformed into something completely different while being in use all the time.

Software must follow the needs of its environment

As written before, software usually needs to be changed continually to preserve its value. Software typically supports or augments processes and interactions in the physical world or it implements virtual processes and interactions that collaborate with other software or it does a combination of it. No matter how, processes and interactions need to seamlessly fit into the environment they work in to provide value. If they do not fit in, they create reduced value down to negative value due to the mismatch and resulting friction.

As the environment software lives in tends to continually change, adapt and evolve, the software living in it also needs to continuously change, adapt and evolve to maintain its value. Failing to keep the software in sync with the needs of its environment means a continuous deterioration of the software.

Software maintenance is not what you think it is

A common mistake at this point is confusing the changing of software with the maintenance of physical goods. Maintaining a physical good, e.g., a car, means to maintain its basic functionality. It does not change any of its functional properties. The software equivalent of maintenance might be regularly cleaning up the database or file systems used by the software or alike to avoid a malfunction of the software due to corrupted data or exhausted file systems.

But even this does not really match it because software does not have any natural wear as physical products have. Also bug fixing cannot be compared to the regular maintenance of a physical product even if it usually is called “software maintenance”. The equivalent of bug fixing for physical products would be a recall of the product in order to fix a shortcoming that already led to or could lead to a malfunction of the product.

But all this is not changing the product itself, its functional properties. Again, this makes software a quite unique material. It is not designed and implemented once and then used according to its original specification. Its specification, design and implementation are changed continuously over the whole lifecycle of a software solution.

AI and the value preservation dilemma

Regarding AI solutions, this means such solutions do not only need to create code once for a given requirement. They need to go back to existing code written by them or someone/something else, understand what it does, understand how it maps to existing requirements, understand how to fit the new requirement into the existing set of requirements and code and how to implement the new requirement without breaking any of the existing functionality.

This would be hard enough if all requirements could be strictly separated in the code. But usually, all those requirements overlap in multiple ways and affect each other. Jeff Sussna recently phrased it this way:

“IT is complex because it has to do more under more interesting conditions, and the use cases all overlap and perturb each other. That will only increase.”

I could not agree more. Besides other things, this means that often a given piece of code is the result of several requirements that affect each other in complicated (or maybe even complex) ways. It is not possible to track the code back to a single requirement. To understand the code, you need to understand all requirements and how they affect each other.

Again, this is something very different than optimizing a given piece of code with respect to some coding best practices. Understanding the code of an existing software solution to be able to safely modify it means to be able to reason about code and how it reflects the underlying requirements and business-level functionality. No matter how impressive the capabilities of AI solutions seem to be: This is a different game and I do not see AI solutions anywhere near being able to accomplish this task. ²

In the end, the value preservation dilemma reinforces the greenfield fallacy, we discussed in the previous post. It reinforces that we almost always live in the brownfield.

Fourth interlude

In this post we discussed the value preservation dilemma of software. We have seen that software – opposed to almost all physical goods – needs to be continuously changed and adapted to the ever-changing needs and demands of its environment to preserve its value. We have also seen that all comparisons with physical goods regarding “maintenance” do not work.

Software is a quite unique material. I can only repeat:

We need to stop comparing software with physical goods if we really want to leverage its strengths.

Which other material can you continuously change while using it until it has transformed into something completely different than it originally was? This is extremely powerful!

But we need to understand and accept that software needs different approaches to deal with it to unleash its tremendous power – approaches we cannot learn from the construction of physical goods.

In the next post, we will discuss the final two issues of software I would like to emphasize in this blog series, the invisibility dilemma and the malleability curse. Stay tuned …