One upon a time there were 3 little race car drivers
There are 3 drivers in a 50-lap race driving their cars as fast and as hard as can be expected in a race to the finish. After 25 laps their tires start to thin out, gasoline gets low, even paint starts to chip off the hood of their cars. Driver 1 and 2 are driving steady and fast but trail driver 3 by about 5 car-lengths as driver 3 drives at unsafe speeds. Driver 1 pulls over for a pit stop and gets 4 new tires and a full tank of gas. Driver 2 does the same but also touches up the chipped paint. Driver 3 decides he has no time for stopping and skips the pit stop resulting in an impressive 2-lap lead on the other cars.
Driver 3 blows out one of his thinned-out tires at lap 85, but is able to hobble forward with 3 tires and a rim. By lap 90 the other drivers with good tires are nearly caught up. At lap 95 driver 3 blows another tire and realizes he in running on fumes. Driver 3 knows he needs one last heroic effort to beat the two cars that are now right on his tail. He switches to a higher gear and guns the engine coming out of a turn. His bare tires can’t take the explosive speed and he careens across the track and into the wall destroying the car and nearly killing him. Driver 1 wins the race with driver 2 about 20 car-lengths behind.
If you have made mistakes, even serious ones, there is always another chance for you. What we call failure is not the falling down but the staying down. - Mary Pickford
Driver 3’s mistakes seem obvious even to someone like me who knows little of car racing. Everyone knows he has to go fast to win a race, but not to the point of being reckless. Everyone knows he will have to take a pit stop, obviously stopping his forward progress, but it is time well-invested to ensure he can finish the race. Everyone knows the more reckless he drives, and the worse shape his car is in will have a cumulative affect making him drive more reckless and deteriorate his car even further to the point where he cannot race anymore.
Driver 2’s mistake is a little less obvious but he did lose the race for a reason. He was smart to take a pit stop, however he was not smart about what he chose to do with his time there. Driver 1 made the smart decision to leave the chipped paint for another time and only change what was required to make sure the race could be won.
Those who make the worst use of their time are the first to complain of its shortness. – Jean de La Bruysre
At this very moment development teams around the world are building applications without pit stops. There’s a good chance you know of one, are a part of one now, were in the past, or will be in the future because it is an epidemic that is more prevalent than it ought to be.
The way I see it there are two kinds of pit stops and more than one way to handle them. There is the concept of mini-pit stops in software development called refactoring which has become so mainstream that refactoring options are now built into Visual Studio. Refactoring is the concept of taking time to improve existing code without changing functionality. The value is often unperceivable by the naïve developer and of course management. In general, right after code is written, when a new feature is added or a bug is fixed, we must always give some thought to changing the design so the new feature would be easier to add, the feature would be easier to update, or the bug could never happen again.
There is also the concept of a large pit stop that is obviously more time consuming and painful. The large pit stop is often attributed to not taking enough previous smaller pit stops. The bigger the pit stop is the more likely it will be put off. The more it is put off the bigger the need becomes until the race car (application) is so beat up, so distorted and uncontrollable, that it falls apart and management decides we have to buy a new car (rewrite). Not stopping for the smaller pit stops ends up costing the business much more money in the end.
There is still much to debate about when it comes to pit stops along the lines of when to take them and what to do while we are stopped. Driver 2 made the mistake in his pit stop to touch up his paint which was cosmetic and had no affect on the future of the race, and in fact cost him the race. Likewise, developers need to be judicious about what gets changed when they invest time to do so. We have a tendency to want to make things look familiar to us, do them our way. In affect we are just skinning the cat a different way and there is no improvement, or the improvement is marginal at best. The best pit stoppers know why they would make any change before making it so they can better foresee the impact. Another possible pitfall of the pit stop is what author Fred Brooks calls the Second System Effect where developers tend to over-engineer a solution now that they have time to address everything they couldn’t the first time around. Like skinning the cat and making cosmetic changes, over-engineering has to be held in check.
Quality is not an act, it is a habit. - Aristotle
The need for time-consuming pit stops can be alleviated by any kind of quality control a development team can muster. This might be achieved by code reviews, pair programming, an easy testing framework, or simply best practices and standards agreed upon by the developers. I state they can be alleviated in order to clarify that they cannot be removed entirely. No professional application worth its bytes can survive and have a decent return on investment without refactoring. Duct tape, spit and glue can only hold things together for so long, eventually broken applications completely fall apart. It is always then we realize that a little preventative maintenance could have helped. An ounce of prevention is worth a pound of cure as Ben Franklin would say.
The inexperienced view is that the methods used to get an application up and running or to figure out how to do something can be the same methods used to maintain, update and fix an application. Often in an effort to get an application to market, electrify a client, impress a boss, just figure something out, or get some dollars rolling in we do what ever is necessary to get something working. However, it is patently absurd to keep banging away on an application with a hammer when the application and its context have evolved in to what is no longer a nail.
In this blog I tend only to deal with software concepts that affect the common business application. The business application has to be one that is intended to last as long as the business and make it more profitable. However a lack of quality control, in this case the failure to recognize the necessity of pit stops, seems to be a major killer of applications, developer’s jobs, and ultimately businesses. Though one could argue that this problem often creates more jobs as managers try adding more developers to fix their problems as opposed to ever addressing the fundamental issue. Right now there are too many businesses losing profit by paying too many developers to maintain applications that should require less to do so.