Outline
Warning: I'm going to tell a short story from World War II. If you have strong feelings about this time in history please skip to after the photograph.
In June of 1941, the Nazi military machine launched the largest military operation in human history. It was code-named Operation Barbarossa. This operation was an invasion of Russia and was executed with astounding precision, achieving unparalleled success. Millions of prisoners were taken, and thousands of miles were covered in an amazingly short time.
And then things started to bog down. The Germans simply underestimated the sheer size and tenacity of the Russian military. One of the key problems was that the Germans outpaced their supplies. They were too far ahead, and supplies (food, fuel, ammunition) could not be brought fast enough and in enough quantity to keep the vehicles and men supplied sufficiently.
As a side note, I'm a huge World War II history buff, and for some reason whenever I hear about operation Barbarossa, I can't help but think "Barbossa" in my mind.
Now you may be wondering why I chose this story in an email about the trade-offs of code quality and velocity. There is a great analogy here. A military force cannot simply endlessly chase success. As Napoleon said, "An army marches on its stomach". Sufficient supplies are critical to lasting success militarily.
The same is true for development. If we simply chase feature after feature, doing whatever we must to complete the feature as soon as possible, grabbing that oh-so-tempting "low handing fruit" we will eventually find that we have "outpaced our supplies". Our inattention to quality - automated tests, continuous integration process health, correct use of design patterns, frequent code reviews and pairing, merciless refactoring, investigating all code smells, upgrading to latest stable versions, and all other related activities - will catch up to us.
The payment will be reduced overall velocity as we are forced to more and more often work around the problems we create in our code, and deal with strange bugs that crop up when we least expect them, in places we couldn't anticipate. And then things will get worse. Morale will drop, turnover will increase, and development velocity will continue to suffer.
Last week I discussed the code smell of "excessively short identifiers". That discussion showcased some code that really wasn't bad, but I showed how a bit more effort will improve the code quality and decrease overall maintenance costs. It's this kind of attitude, and strict diligence in code quality that will keep overall velocity at its maximum.
As Uncle Bub so eloquently put it this morning: code quality IS speed.
As we refine our ability to code we must always remember to devote sufficient time to refactoring and code quality. That includes time to study the art of software engineering and continuously reflect on our own performance and capability so that we can constantly improve.
Find this blog helpful? Forward it to a friend.
Want to get more content like this delivered to your inbox? Signup for my newsletter here.