In January, I read a news story about a woman who wanted to drive from the outskirts of Brussels to the train station to pick up a friend. What should have been just a 38-mile drive turned into an 1800-mile odyssey across Europe because the car's navigation system sent her the wrong way.
The navigation system sent her via Zagreb, Croatia and apparently she was so preoccupied that even having to stop for gas several times did not tip her off that something might be wrong. She crossed five borders and saw traffic signs in different languages. The people at the gas stations where she stopped did not speak her language. The names of cities and towns were not familiar. Yet she did not doubt her navigation system until two days later when she realized that she may not be in Belgium anymore.
It is tempting to make fun of this woman's blind trust in her navigation system. But at least she had a tool that helped her stay on a course. Her only mistake was that she did not verify that this course was in fact the right one. Many software development projects do not have a defined course or even a defined goal to begin with. Some teams develop software and deploy it into production without any tests and without monitoring on the application or system level. When errors occur they have no clue as to what the root cause is. Not that it would matter mind you, as they probably do not have a process defined in which to deal with the errors anyway.
Just checking how fast you are going, for instance by measuring your team's velocity with burndown charts, is not enough if you want to make sure that you reach your goal. Going in the wrong direction at a higher speed is worse than going into the right direction at a lower speed. If you do not want to develop your software with blind air navigation you need to continuously make sure that you are still on course. Acceptance tests tell you that you are building the right product by ensuring that the software does what it is supposed to be doing. Unit Tests tell that you are building the product right by ensuring that the code works correctly. Software Metrics provide you with the telemetry needed to detect when you are going into technical debt, at the first possible chance.
The architecture of a software is defined by its quality goals. These goals are commonly referred to as the non-functional requirements of the software. They include but are not limited to functionality, usability, reliability, performance and supportability. These aspects of software quality are tangible to the end users and make up the external quality of a software product. The internal quality of software on the other hand is virtually non-perceptible to end-users. But aspects of internal software quality such as readable code that is easy to understand, adapt and extend are of vital importance to the developers. If the internal quality of software is low, then implementing future change requests will become more and more difficult and thus expensive over time. The danger will increase over time, even small changes to the software will have unexpected side effects. It is crucial for every software project to define not only quality criteria, including external quality, but to also ask for a sensible level of internal quality.
Ward Cunningham's metaphor of technical debt is invaluable in making the cost of low internal quality transparent to all stakeholders of a software project. The metaphor compares bad code with a financial loan that has an interest on it. A loan can be a good idea if it helps the project to ship a product quickly. If the loan is not paid back, however, by refactoring the code base and thus improving the internal quality, a considerable amount of additional cost in the form of interest will pile up over time. At some point, the interest payments will reduce the financial scope, until finally one has to declare bankruptcy. With regard to software development this means that it is no longer economically feasible to maintain the software.
The main goals of quality assurance are ensuring that the software's quality goals are reached, making the costs and benefits of internal quality transparent to all parties involved, and ensuring that the developers do not stray from the design that is laid out by the architecture. Assuring quality must not be an afterthought. It is a process that starts at the beginning of software development and must not end with deploying the (first version of the) software into production.