What do we mean by software volatility
Software volatility is the variation in existing working functionality of a software product. A less volatile software is one that is quite stable in how predictably it performs all its user functions over time. Of course, we all want such systems and want that new features get added over time.
Users and customers convey this expectation to the leaders of the software team. The leaders communicate this to the engineers. They may even have quality metrics that measure number of new defects per release and keep them as low as possible. They may even judge the software team's capability based on this. THIS IS A FOLLY. Complex systems do not evolve in this way (may be simple software systems do). Similarly for customers to lose their confidence when a product degrades in certain areas once in a while is a mis-judgment. Why is this a so?
Low volatility system
When a software engineer is asked to add new functionality - he/she may instinctively or due to the nature of work environment avoid changing code that is already working and adds the new functionality in a way that the code for both old and new don't overlap much. This is a low risk way of adding software features and is quite common in our experience. When this process is repeated over and over again - everyone is happy.
This was one example but a software team can take other types of such short-sighted approaches:
- forking the code for a new customer because it is too risky to generalise existing code and jeopardise existing customers functionality
- not upgrading the underlying software libraries because the impact can be high
- not changing the code so that it more testable
- not deleting code
But this cannot last very long. Slowly this option of not changing the old code much (hence not improving it) and adding only the new becomes less and less available to the engineer. This leads to a very bad place. Now, there is a lot duplication in the code. Changes need to be made in several places for one thing. Some changes get missed out. But most importantly - it is no longer possible to reason about the code and change it. This is because the code was written with a different objective in mind - deliver new things without breaking old things - and not understandability of the code. Such low volatile software hide much bigger risks.
Why you must not take volatility for sign of a problem
Volatility by itself is not what we want, but if we build the software the right way there is no escaping functional volatility. Making software involves regularly improving the internal structure and organisation of the code - to be in line with the new reality i.e. updated functionality, usage, ecosystem. This internal improvement while in very short term (a few weeks) introduces defects, but the decision to go ahead and take this risk, improve the code, is essential to creating long lasting good quality software.
Published on: 02 Jun 2023
Author: Vivek Singh