The ultimate way to effective software evaluation

I have a simple question: what is quality? Seems like an easy thing to explain. However, when you try, it does not look like a piece of cake. I have been in software development for 30 years and all this time I promised my clients to produce quality software. And all my fellow colleagues did the same. But what did we promise in reality? Some define quality as the level of customer satisfaction. Others say it is about meeting the requirements of the customer. For those “living” in the tech world, it is the state of software being free from defects. To me, the latter is closer to the real world but… it’s so boring for customers. Of course, they want quality but consider it “granted”. As such, this “boring” subject is very often excluded from consideration and… budget. Technical debt as a new vision/dimension of the software quality We decided to fix that by intensive research on what is the quality of a software product and how we can manage it efficiently. We started with the replacement of a boring and almost undefined term, “quality”, by the techy but more meaningful “technical debt”. As such, we see the quality of a software product as amount of various technical debts embedded into the product and delivered to end-users.

Industry best practices state that technical debt is any code added now that will take more work to fix at a later time. The source code is really one of the most important things in the software. The higher the number of problems in the source code, the more redevelopment is required. This is how the industry understands the technical debt. However, having been tackling this for many years, the technical debt acquired a different shade. For us, it is product non-compliance with technical guidelines and business objectives that negatively impacts business results.

State-of-the-art software assessment approach

The technical debt is like a tiny tetra fish that exists in thousands of various species. It’s like small, insignificant, sometimes “locally beautiful” trade-offs of quick solutions. When technical debt piles up, we pay an “interest” in the form of harder maintainability, mediocre user experience, productivity decline, and overall higher costs. The higher the number of tetras are in your aquarium, the more fodder is needed and the more often it should be cleaned up. We got all those little fish in one aquarium and created the technical debt reduction platform, TETRA. How do we know what really matters in software products and can assess both technical and business sides? First, we identified eight dimensions of software product technical debt:

• Source code quality
• Usability, UI & Documentation
• Security
• Performance
• Business logic
• Architecture quality
• Data quality
• Open Source code use

Each dimension is measured as per critical metrics and levels they should achieve. It allows receiving a comprehensive product assessment with very concrete recommendations. With this approach owners understand how the product actually “feels”. It gives a full quantitative assessment of the product quality.

Why assess software differently?

The important thing about this approach is that it is not merely for techies. It is an asset for everyone working with the software product. Developers and testers get a non-prejudiced assessment of their work. Managers receive the feedback on the product’s overall capacity, while users get the reliable and well-performing product. Moreover, the processes used for the product assessment train the team to follow best practices during the product development. This increases team proficiency and consequently the quality of the product.

In line with that, the approach provides the product owners and investors with proper business information. The fair analysis of the product tells companies whether the product is ready for the market launch. In case the product already works as the company offering, owners can estimate its efficiency and value on the market.

The investors can evaluate the state of a product for purchase, better define the product’s market value and assess the investment risks of the intended transaction. Simple bug fixing, or removal of code duplications will never do that. These activities just not imply “weighty” business facts.

If you still think that technical debt is only about code, our approach makes you think twice. Running such an in-depth analysis has shown that technical debts are about the overall product quality. Checking the software product code is not enough for understanding product efficiency, you have to move further.

As soon as you start doing it, the benefit is literally priceless. First and foremost, you get the opportunity to pay the product debts before they turn into pains. You put them under control. You evaluate the progress of the product development and improve implementation. The assessment gives the understanding of business and market efficiency too.

The bottom line is that the quality of software affects all facets of the business. It is not the sole concern of software developers, but it is also an issue for software owners and even users.

The goal of all of that is to quantitatively evaluate the state of a product to achieve a better result. Without a comprehensive measurement, there is no way to understand quality and control it.