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.
Map data © OpenStreetMap and contributors
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. In regards 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. Quality
Assurance 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.
This article originally appeared in Web & PHP magazine.