Page 177 -

leaking into a new build. By running the unit tests afterward, he can ensure that the build he
is checking in works properly and that no defects have been accidentally introduced.

Broken Builds
Most programmers on the team know that they need to unit test their code. And when it
comes time to do it, they try to be as thorough as possible. Before a programmer delivers a
build to QA, he goes through each feature and clicks every button and UI widget to ensure
that they seem to work. The programmers always make sure to take at least a few hours—
sometimes an entire day—after the software is built, making sure that it works.
But all of that effort does not seem to matter. No matter how hard the team tries, the lead
programmer always seems to get into the same argument with the lead tester in the status
meeting after the first build of a project is delivered. The lead tester reports that the tests had
to be halted because some basic functionality is missing or broken. The programmer explains
that the entire team took a lot of their time to unit test the build, and that everything looked
like it worked. The QA lead explains that this clearly wasn’t enough, because the software is
too broken to be tested. The programmer gets exasperated—isn’t it the job of the QA team to
figure that out and tell them what to fix? In the meantime, the testers have to sit around
and wait for the new build, and their entire schedule is blown. There never seems to be a
solution, just a lot of work to try to get the build good enough for the testers.
A software tester will often find defects that slipped past the programmers, because her
test strategy causes her to take actions in the software that require many different units in
the code to work together. Had the programmer built a unit test suite that thoroughly
tested each of these units, he would have caught many of those problems before they ever
reached the QA team. More importantly, if the programming team adopts a test-driven
development strategy, each programmer will be clear on exactly where his responsibility
lies in verifying the quality of the software. The team will know that they test each unit,
letting the testers concentrate on verifying that the requirements have been met.

Spaghetti Code
Maintaining old code is the least desirable programming job in many organizations. Code
that was patched by a dozen different developers over the years seems to be held together
with the software equivalent of duct tape and paper clips. With each successive version of
the software, certain aging functions just seem to get longer and more convoluted. Trying
to track down bugs is a tedious and frustrating task, and even the simplest modifications
can be daunting.

In an environment where aging code has turned into a twisted mess of complex and tan-
gled execution paths, loops, blocks, and patches, the team is usually at a loss. Everyone
recognizes that it’s a problem, but the only solution that anyone ever suggests is rewriting
some, or even all, of the code. Sometimes a rewrite is justified by upgrading to a newer
version of a language, programming tool, IDE, database, or operating system—but the
team knows that the only reason the idea has merit is because the old codebase has essen-
tially become unmaintainable.

DESIGN AND PROGRAMMING 169