Digital transformation and software quality
Software quality is one of those guarantees, often neglected, within the scope of a project development on Digital Transformation. The first release of a software project is usually 70% around it being fit for purpose on business requirements and 30% on its quality. The latter is not just a stylistic exercise and from the second and third releases, the percentage proportions will radically change moving all the focus on its value. This easily translates into maintenance and adjustment capabilities.
It means that once the first milestone of set releases is done, the whole game will be played around the functionality and the elegance of the code (easy to be read and understood by those with a background in different programming languages) and on its infrastructure, often extremely undervalued because it is a hidden feature, not recognizable to the ones who are not experts.
Every single time a new feature is implemented in an IT system, dependencies and interdependencies are generated and one of the objectives of high-level software development is to reduce the number of such dependencies by making them simple and obvious.
When do we have dependencies or interdependencies?
These happen when a “piece of the code” cannot be understood or amended because it is linked to another piece of code. The code reflects operational processes that can be potentially reduced to steps or phases but, realistically speaking, they are interdependent from a structural point of view. A workflow consists of a series of actions that have a beginning and an end and are linked together. If you think about cooking pasta, there are different steps in the process: you need to get the pan, put water and salt in it. Then you need to put the pan on the stove, choose the type of pasta you want and, at the right time, put the pasta in the pan. Once ready you need to drain it in the colander.
We also need to add an extra element that is needed to identify the quality of the software: the obscurity rating. Obscurity happens when important information is not obvious. For example, the excessive abstraction of the name of a variable interferes with the whole comprehension of its reference. When we have non-coherent elements, the repetition of the name of a variable makes its use difficult to understand.
The complexity, which is what sets the price for application management and maintenance, happens because thousands of little obscurities, dependencies, and interdependencies accumulate in time.
Having many lines of code means having more unknowns and interdependences which might lead to constant interventions to have bugs fixed. This can lead to having other components of the application which can then break resulting in more bugs – this will turn into a constant.
The reality is that complexity will make any changes in the existing code difficult, risky and expensive.
Different organizations encourage a tactical mentality focused on making the features required by the client to work as soon as possible so the returns are maximized. This is a typical approach for those who have confused software with the assembly line system, typical of factories in the analogic industrial era.
If you want a good design and a good application it is needless to say that you need to have a strategic approach that gives priority to investing time in it. Clean projects can be then produced and problems can be solved in advance. Such an approach gives better projects and, in the long run, is cheaper than the one described earlier.
The main objective of such an approach is to make new features work or correct some bugs. If you are developing tactically you are mainly trying to complete an activity as rapidly as possible.
“It just needs to work” an approach that is not good
Some clients are satisfied in seeing many people devoted to the projects (Full Time Equivalent = FTE) as it translates into having a lot of code produced rapidly: many people sitting in the same room (Covid permitting), busy on their laptops. Among all these people there is always a genius who develops faster than the others and when a new function needs to be implemented “no one does it better than him”.
In some organizations, the so-called geniuses are treated as heroes even though, together with their big teams, they leave a lot of unresolved problems as their main objective is to write code without communicating with each other.
The result of such an approach is that whoever will need to work on that code one day will face some black-boxes which will be extremely difficult to find a solution to.
By now I am sure you have understood that having a code that works is simply not sufficient. The bigger part of the code of every system has been written by extending the pre-existing code. Our job as excellent software developers is to facilitate the scalability of the system. The “it just needs to work” rule does not work even if it needs to work.
The objective of a company that develops software in 2021 should be to produce code with an excellent design that really works.
This is an approach that requires the company to develop an invested mentality that can give the code the right skeleton devoting the necessary time to the start-up phase to get some benefits in the following developments. You can then avoid the problem of the Broken Window Theory: to be challenged continuous refactoring is needed (even in Ancient Greece they knew that prevention is better than the cure), leaving space for implementations that require low efforts.
Our approach is all about moving fast but by giving a solid skeleton and structure to our code, with an intent finalized to reduce complexity.
The age of “Move fast and break things”, a famous Facebook motto, has now come to an end. The Minimum Viable Product needs to be substituted by the Minimum Virtuous Product which is defined by “Move Fast with Stable Infra”.
Why using slogans does not work
Using slogans when you are talking about Digital Transformation is just nonsense – implementing innovative software is a completely different thing. Those who talk about Digital transformation as a fast and simple process, using some ready-made sentences, have probably never implemented a complex system.
Software projects are engineering projects which try to solve and implement complex solutions. The problem is that engineers are often extremely optimistic and execution times always double or triple compared to the initial assessments. A similar situation already happened in past centuries – just think about Brooklyn Bridge. The same thing can easily happen to the development of a new software although you need to add an extra unknown: cognitive work is similar to a living being. It is not an inanimate and static object. The result is an organic system that constantly evolves.
Digital Transformation is set to disrupt our world by producing historic business changes. If you waste a lot of your time waiting to address your software design issues, you are only going to see those issues become bigger and bigger.
The complexity around the solutions is going to be more important from an application and organizational level. Postponing will become natural and you will lose the competitive advantage on your competitors who will have worked in a clever way and who will turn you into just a simple “follower”.
You might also like:
Digital Transformation: when pure strategy is better than videogame technology
How to be a business superhero in 3 days
5G and IoT: the Fourth Industrial Revolution
