Now that we’ve covered the elements that make programs high-quality here’s a non-exhaustive list of ways to actually achieve it. None of them are absolutely necessary for achieving the quality, but they certainly help a lot.
Many people often confuse them with quality. “This software has God-damn awful code, so it’s a pile-of-crap.” Well, what do the users care how bad the code is, as long as it is functional, has all the necessary features, and is (mostly) bug-free? It’s important not to confuse quality with the ways to achieve it.
The aim of this section is to briefly cover as many measures for achieving good quality as possible.
The more modular a project’s code is, the easier it is to change it, understand it and extend it, and the faster development will take. Refactoring is the name given to the process used to transform code from sub-optimal and “ugly”, but still mostly functional and bug-free code, to a code that is equally functional but more modular and clean. See the Joel on Software excellent article “Rub a dub dub” for some of the motivation and practices of good refactoring instead of throwing away the code and restarting from scratch.
A reviewer of an early version of this article told me about an early and relatively large PHP code of her that was badly written, relatively buggy and yet proved to be popular among some of her clients, who have deployed it on many hosts and won’t effectively upgrade it. So she still has to maintain it, even though she’d rather not recommend it. She claimed that this is an indication that such low-quality in code, is a criterion of low-quality.
She has a point in the fact that usually badly-written or non-modular code results in more external low-quality factors such as bugs, security problems and lack of extensibility. However, even if the code was extremely well-written it is likely that it would need to be maintained, extended, and corrected. And if the clients in question don’t have or don’t want a good way to pull changes from a central place, or install updates properly, it’s a procedural and organisational problem.
Organisational quality deserves its own separate article (or arguably book, web-site, or even more than one book), but external software quality (much less internal one), is not a substitute for it. Please refer to a partial list I prepared on a different article, and my software “gurus” links on my home-site’s links’ list.