Analyzing Software: Technical, Tactical and Strategic Qualities

Building software always comes with significant investments, but should be only a fraction of the possible long term gains. To ensure the software yields the expected outcomes, not only for the first releases, the first two years, but long term, the software must be developed with different qualities.

Long term? How many systems does your organization have, that are 3+ years old and are not limiting the potential capabilities of the company [without reinvesting/rewriting them]?.

In this article a small framework to assess the quality of your software is presented. To ensure software is profitable for the company during its full potential, we analyze the software on 3 different levels: Technical, Tactical and Strategic. This can be the first step to improve the earn backs of your technology/software investments.

Technical Quality

When people learn how to program, the syntax of the language is explained. Next in detail is explained, how to do recursion, with the termination condition; how to do multi-threading, with thread coordination and shared memory; how to read and write from disk, how to handle the 'EOF', etc. Without this knowledge, your system might run in a happy scenario, but there will be many conditions in which your system is malfunctioning, or even crashing. This is the technical quality of your system.

In other words, the technical quality is related to the ability of the software to yield correct results in all circumstances.

When you have system with low technical quality, relatively limited resources are needed to improve the quality. One or more maintenance releases can be leveraged to significantly improve the quality. What is needed are technically sound engineers, a quality that is easy to assess.

Tactical Quality

After you have developed a system with the highest technical quality, there is no need for change. Unless the initial set of requirements is changed, the business need. Unfortunately those are always changing. That means we need to alter the software. Independent on the technical quality, it can be anywhere from super easy to extremely hard to alter some behavior of the system. If the behavior is not isolated, but spread out and duplicated in the system, it becomes really hard to alter that behavior.

The tactical quality of a system is related to the ability to change behavior of the system.

Improving the tactical quality is hard to do for systems that have really poor tactical quality. It normally means rewriting the complete system, introducing a System X+1 version. Identifying that it is costly to change a system is easy, to create a system that is easy to change is more complex. A strong architect is needed that guides the development team to a good result, an ability that is less common and harder to assess.

Strategic Quality

Who determines what systems are needed? In many scenarios projects yield software systems (1-on-1). But projects are naturally not organized around software systems, but business needs. This means that systems get deprecated/replaced by other systems, just because the scope of the system is no longer meaningful.

The strategic quality of a system is related to how long it will yield benefits to the organization, and not limiting or endangering business opportunities.

This requires a strong CTO or chief architect to ensure the right enterprise architecture is in place. A current state and future state, including an evolution plan must be developed. Without this explicit guidance, systems barely have a one year span it really realizes its full potential to the business, before becoming a limitation. Independent of the strategic quality, the development cost of a system is equal. This means that the right strategic person can multiply the benefits/earn backs (revenue/cost reduction) of your investments in technology.

Conclusion

Almost all cost of developing software is related to human resources - therefore it really matters who you hire. A simple assessment can show where you are strong, and where you can improve. If you have the classical "rewrite a system" within 3 years of its life time, it is most likely you have serious issues with strategical quality (this might be more common than you think).

Fixing software is good, but when the software gets outdated soon, you are likely not able to earn back your investment in fixing the software. Neither is replacing the software an option when you are not confident the new software has a long lifetime in which it realizes its full potential. This means, without vision, without being able to improve strategic quality, you are stuck in the same state, despite the amount of investments you make in software.

Strategic quality comes not only from hiring the right persons, but also enable them to make the decisions how to transition. Thus improving overall quality means investing in a target state, and not limit investments to only the current state!