Evolvability
EVOLVABILITY
| TTM | ROI | Sellability | Agility | Reputation |
The ability to evolve a feature, system, or practice into something better.
The ability for software to evolve is another important, but often neglected, quality. Evolvability enables (and encourages) us to successfully change (improve) the way an existing solution works; possibly to withstand higher loads, or to enhance a solution to better cater to a business problem. It works at a higher level than certain qualities (like Scalability or Maintainability), as it relates to our ability to evolve a current solution for any purpose.
ASSUMPTIONS HAMPER EVOLVABILITY
A system's evolvability is typically hampered by the Assumptions we make and embed within it during its lifetime (e.g. tight-coupling), which prevents or obstructs change when it's required.
We might choose to evolve a system to change the existing implementation, or to migrate to a different technology in order to support a business goal (e.g. increase useability by enhancing Performance). However, it's one of those qualities which is easier explained by its absence.
A failure to evolve may lead to:
- A failure to Innovate. If you can't modernise your solution, then you're less able to innovate. In a world more and more influenced by technology that's tantamount to corporate suicide.
- Poor Security. Your system gathers security debt as it can't be upgraded. At some stage you're unable to resolve (critical) vulnerabilities, leading to potential reputational harm.
- Poor Scalability. If you can't improve your system, then you can't cater to new non-functional expectations, such as modern “web-scale” expectations.
- Poor Agility. Such as an inability to cater to modern customer expectations. A business unable to support a desired level of agility, due to poor evolvability, faces a dilemma; do they let their customer down and lose their custom (possibly suffering reputational damage), or do they choose to work around (hack) the problem and exacerbate complexity and evolutionary issues? It's almost certainly the latter, and whilst it's likely the right decision, we should never have been put in this position in the first place.
- Reputational harm. You can't undertake the necessary evolutionary (or transformatory) steps necessary to compete with others, which becomes obvious to potential customers.
CHANGE FRICTION
The whole evolutionary challenge relates to something I call Change Friction. The ability to change becomes increasingly difficult, until the effort becomes greater than the benefit. This leads to dissatisfaction, poor morale, an unwillingness to change, and poor stakeholder confidence (Stakeholder Confidence) and engagement (i.e. the death of a product).
At a more fundamental level, we may see one (or all) of the following consequences.
You may be positing that we can easily solve this problem? We simply tell engineers to build solutions or use technologies that can be evolved. Unfortunately it's not that simple. Evolvability is a multidimensional problem, affected by many things that aren't always in our control (Control), including: an Immediacy Bias (on the part of both the engineer and the business); a lack of clarity (and measurability) on what evolvability means; the sometimes disproportionate (future) effect of a seemingly innocuous assumption (Assumptions) on a system, and thus on the business; or rapidly changing industry standards and technologies that void earlier assumptions.
Of course, one shouldn't be too disheartened. Whilst there are no guarantees, we can certainly reduce the likelihood or impact of evolvability friction, and be alert to the signals (I noted some earlier) of a forthcoming problem.
DOMAIN POLLUTION
Domain Pollution is one major source of poor evolvability. The idea is simply that one domain becomes polluted by others, thereby impeding its ability to evolve due to its significant Blast Radius (and therefore, risk) on the overall solution.
Conversely, "clean" domains (typically protected by an interface) can protect the domain, and therefore the business' Agility and Reputation.
PILLARS AFFECTED
TTM
Big Bang Change Friction (Change Friction) is one of the biggest issues here. TTM is impeded by the scale of the change required to evolve a solution, should that quality be absent. This is one reason for the popularity of loosely-coupled, low-grained solutions (such as Microservices).
ROI
To illustrate the importance of evolvability on ROI, consider this anecdote. I once worked on a monolithic application that suffered from poor evolvability (mainly due to Domain Pollution). We needed to evolve it to support the business' aspirations (it didn't scale, the technology was antiquated, it hampered our productivity - the usual monolithic challenges). Yet, effort and risk (Change Friction) prevented its evolution, eventually leading to us building a new system (at high cost). If the existing system had better supported evolvability, it may have survived longer, or sold better, and thus generated greater ROI.
Procrastinating on technology upgrades (Upgrade Procrastination) also leads to evolution challenges and potentially a product's early demise. The same monolith I described earlier suffered from this too - upgrades were neglected (initially, through choice, but later, without one), to the point that it eventually caused Big Bang Change Friction (Change Friction), fear, and its early demise.
SELLABILITY
A solution that lacks evolvability makes it difficult to support prospective customers' needs. Businesses that can't do this will lose potential sales to competitors who can.
AGILITY
Evolvability relates to how easy it is to evolve a feature, system, or even a business, into something better. Systems that exhibit a high degree of evolvability promote business Agility and more manageable change (in whichever form it takes). Conversely, hampering evolvability may cause Technical Stasis and Cultural Stasis, leading to the inability to Innovate, inflexibility in sales, and a general lethargy within the business.
TECHNOLOGY MIGRATION
One Monolith I worked with was in desperate need of a technology facelift. Without undertaking a technology migration (i.e. evolution), we would be unable to support and grow the business. Yet the business was so focused on functionality (Functional Myopicism), it procrastinated until the technology evolution became impossible. This had several (severe) ramifications:
- Productivity was poor. Each change was costly, and therefore hotly contested (i.e. Political Change Friction).
- Security concerns, due to continued use of antiquated technology.
- Technical and cultural stasis. People became accustomed to the slow pace of delivery, affecting their motivation. There was no sense of urgency.
- It lost its agility.
REPUTATION
Evolvability relates to our ability to easily evolve areas of a system (or business) to improve it. This might take the form of introducing a better design, technology, practice (e.g. Agile), team structuring, or a cultural change (e.g. DevSecOps). A failing in any of these suggests that we can't undertake the necessary evolutionary (or transformatory) steps required to compete with others, and thus suffer from reputational harm.
SUMMARY
The ability to evolve a system (or business) ensures that it remains in a healthy state and can significantly increase the lifetime of a software product. In short, it helps protect the integrity of a solution.
Of course we'd all like our solutions to be endlessly evolvable, but that's not entirely practical. Even if we spent every waking moment trying to ensure evolvability, it doesn't guarantee a future-proof system (there are simply too many variables), and we'd have expended many cycles which could have been better spent on building out new features. A happy balance is advisable - whilst it might take some effort to evolve a system, constraints shouldn't make it an impossibility.
FURTHER CONSIDERATIONS