Improving Quality In Software Development
What are some strategies for improving quality of a software product? Let's take a brief moment to consider quality itself, for it is a fascinating subject.
What Is Quality?
There is the issue of what "quality" means in the first place. Consider Ruby and Java. A typical Ruby developer would consider Java excessively verbose. A typical Java developer might consider Ruby too dangerous, or unpredictable. Is code written one of these languages of higher quality than code written in the other?
As of 2017 there is a large number of static code analysis tools in existence for most if not all commonly used programming languages. These tools define quality through objective metrics like the number of lines of code per method, or whether parentheses line up vertically with function arguments. But, such a narrow definition of quality leaves something to be desired.
I personally consider shipping software as important as building software. The best, most beautiful, totally intuitive, completely bug free software is useless if it is never finished, never released to users or customers. In this light, I like the following definition of quality:
Quality is the property of software to continually exceed its users' expectations.
It is easy to see that bugs detract from quality, as a bug - almost by definition - is when a piece of software operates in a way that is contrary to its users' expectations. At the same time, in an ecosystem of thoroughly buggy software a program that is less buggy than the alternatives - though not at all bug free - would be considered to be of pretty good qualtiy. That said, users adapt to software they use, and over time would increase their expectations. Quality is a constantly moving target.
The Human Factor
The stated definition of quality always has a subjective component. The example of a not very buggy program in a very buggy ecosystem is a great demonstration of the fact that different people, or people in different circumstances, would assign different quality to the same program. What may be surprising, but is logically necessary if you think about it, is that software engineers, and software companies, judge quality of their software from the standpoint of their own capabilities, knowledge and biases.
For example, an engineer who is used to manually testing their code would generally believe that code with a "fairly small" occurrence of regressions, say, taking 20% of the engineer's time to resolve, to be of good quality. An engineer used to test-driven development and comprehensive test suites would consider the same program unacceptably buggy; such an engineer would expect to spend maybe 5% of their time dealing with regressions.
Improving Quality
Companies sometimes find themselves needing to improve the quality of their product. This is usually a difficult process, because - as we established - quality is subjective, and most people don't recognize that higher quality is possible (since they don't know what it looks like), plus some people may lack motivation to change their thinking and processes to produce higher quality software.
By Osmosis
The easiest - or the most difficult, depending on organization - method to improve quality of a product or a team is to hire people operating on a higher quality level. Going back to our example of testing manually vs having an automated test suite, hiring engineers familiar with automated testing and putting them on the project in need of such testing is the quickest way to improve quality of said project.
There are two challenges with hiring more talented people: One, hiring may not be an option in the first place. And two, people who are doing the hiring often don't have the skills that they are trying to hire for (otherwise the company wouldn't be in its situation) hence whether a company ends up hiring candidates who would improve the quality of a project or those who would maintain the status quo is often left to chance.
By Learning
Engineers are able to increase the quality of their own work by learning about new techniques, patterns, technologies and paradigms. Good engineers are constantly doing this. This is why talented engineers are constantly improving the engineering output of the companies that employ them - the engineers raise quality of their own work and in the process take the company with them.
A company can aid this process by encouraging innovation among its engineering staff. This can take many forms - from Google's 20% time to allowing use of a new library for some task, internal tech talks and presentations by engineers, rotation of engineers across projects and potentially across disciplines like frontend/backend.
By Recognition
In most companies, seniority trumps talent. It takes real engineering leadership to recognize talent, especially among people who are not at the top of the organizational food chain. The reward to the company for doing so is talented engineers are also frequently highly motivated engineers, as talent is a function of motivation and inner drive. Simply giving talented engineers recognition and appreciation of their work improves their output, both in quantity and quality, which ultimately results in the company having a higher quality product.
One way of recognizing in house engineering talent is supporting open source/free software contributions by the company's engineers. Not only is the act of doing so an ego boost, releasing internal software publicly often makes the developers clean up the rough edges, improving the quality of the software as well as potentially improving the engineers' skills if they, for instance, integrate a new-to-them testing framework to test the software they are releasing.
Related: practical test-driven development.