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 \u201cliving\u201d 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\u2026 it\u2019s so boring for customers. Of course, they want quality but consider it \u201cgranted\u201d. As such, this \u201cboring\u201d subject is very often excluded from consideration and\u2026 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, \u201cquality\u201d, by the techy but more meaningful \u201ctechnical debt\u201d. 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.\nIndustry 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.\nState-of-the-art software assessment approach\nThe technical debt is like a tiny tetra fish that exists in thousands of various species. It\u2019s like small, insignificant, sometimes \u201clocally beautiful\u201d trade-offs of quick solutions. When technical debt piles up, we pay an \u201cinterest\u201d 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:\n\nSource code quality\nUsability, UI & Documentation\nSecurity\nPerformance\nBusiness logic\nArchitecture quality\nData quality\nOpen Source code use\n\nEach 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 \u201cfeels\u201d. It gives a full quantitative assessment of the product quality.\nWhy assess software differently?\nThe 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\u2019s 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.\nIn 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.\nThe investors can evaluate the state of a product for purchase, better define the product\u2019s 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 \u201cweighty\u201d business facts.\nIf 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.\nAs 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.\nThe bottom line is that the quality of software a\ufb00ects 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.\nThe 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.