| Software quality is one of my main professional areas of interest. I agree with the general sentiment. Things have improved in recent years though, in part on account of movements like software craftsmanship, habits like clean code and also because software is becoming more easily and more rapidly testable due to better testing frameworks. Testing frameworks are only one part of the equation. As you stated correctly software quality starts at the beginning i.e. with the requirements or rather even earlier when defining your values and expectations for your project and the software you create for it. There's no shortage of tools for this aspect of software quality either. Those are less rigorous though and emphasise communication rather than true / false (test succeeded / failed) outcomes. Communication is a vital component of good software quality but it has a way of becoming an end in itself rather than a means, e.g. in the form of pointless, cargo cult meetings. Furthermore, in order to accurately measure software development outcomes it is essential to have clearly verifiable acceptance criteria. Defining those can be time-consuming. Simply put, software quality requires investment, both in terms of time and money. Not investing in software quality means taking on massive technical debt. It's unfortunately still a common practice because often a lack in quality will only come back to bite you after some time. It's relatively easy to temporarily cover up and paper over quality deficiencies by implementing workarounds or simply by putting in extra hours. Those temporary measures aren't sustainable in the long run though. They just lead to more technical and organisational debt. Ultimately that debt can become unmanageable. Much like in the boiling frog parable that increase in debt happens very gradually so it's often not perceived as a problem until it's (almost) too late. |