Collective Wisdom from the Experts 5
Unfortunately, they discover something odd with the features that Bernie imple-
mented. While Bernie has programmed in the new functions fine, now a few
things that worked before don’t work anymore. The customer marks these as
defects, and you ask Bernie to fix them. The customer tests the features again.
Now even newer, stranger things seem to be broken. What’s going on here?
If you have a child, you know what is happening. Bernie has created a Whack-
A-Mole application. Whack-A-Mole is a toy. Kids are given a wooden ham-
mer to strike moles that pop up at random. It’s fun for them to be surprised
by which mole pops up next. However, fixing applications with broken code
popping up at random places is not fun. It is frustrating, unpredictable, and
it slows your product development. Bernie was sprinting initially, but he was
running in the wrong direction.
While Rob appeared slower at the outset, he was actually creating superior
code. His pace proved sustainable. The better quality of his initial code helped
him make workable changes quickly. Plus, the tests he wrote in the beginning
gave him instant feedback regarding whether or not his new code was compat-
ible with other parts of the application where the code was used.
When measuring time for a feature implementation, do not consider only the
time it takes to write it in the first place. Add the time it takes to enhance,
fix, and improve the code. Writing good quality code and tests takes time. It
appears to be a short-term loss. However, it comes with a long-term gain.
Ask yourself if you want speed, or if you want to savor sustainable progress.