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.

If you can’t explain it simply, you don’t understand it well enough. - Albert Einstein.  

I think it is safe to say that Albert enjoyed thinking things through until he understood them well enough to explain them simply.  3 years ago to the day I started a blog to challenge myself to see if I understood software development practices well enough to explain them simply. Often I fail with verbose explanations of concepts, which according to Einstein means I must not have a complete grasp of them yet.  But overall, I consider the blog a success. Granted with the insignificant number of subscribers and only a couple hundred page views a month, I don’t think I’ll be quitting my day job. However, that was never the point.  

By thinking things through, verbalizing them, and discussing them outside of myself, I have gotten a clearer understanding of the whats and the whys of development. I’ll go so far as to say that over the past 3 years the blog, the 65 pages of notes yet to be clarified and simplified, and the ensuing conversations have been the main catalyst for my improvement and overall development as a software developer.  

For what it’s worth, I recommend the same for any developer. Try writing down what you think is most important about development, or what drives you crazy etc. You may find that you can’t, because you can’t verbalize what are just abstract judgments. You may also learn some things are not as important as you thought. Best of luck.

One of my favorite metaphors in regards to software development is that of Broken Windows. I first read about the theory of Broken Windows three years ago in the book the Pragmatic Programmer. The theory comes from research done in inner-city neighborhoods where a psychologist noted that when broken windows were not quickly fixed in buildings a sense of abandonment and general culture of disregard for the building took hold. Soon graffiti, trash, and more vandalism became common place. The solution: don’t allow broken windows in the first place, but more importantly, fix them immediately. When the windows were fixed quickly the exact opposite culture set in. A culture of respect and perceived quality soon meant that fewer windows, if any at all, would be broken in the future.

This parallels software development if you consider things like quick hacks, poor error handling, missing abstractions, lack of standards, etc as broken windows.  When they are tolerated the same theory suggests that the culture we are instilling only perpetuates more trash and development-vandalism in our project. This is one truism about development that I believe very strongly.

If only software development broken windows were so obvious, so definite. Recently I mentioned to another developer that a metaphorical window was broken, he suggested it was merely scratched. Later I proved that a missing abstraction broken window led to breaking a standard we had all agreed to and I was concerned about what else these broken windows would lead to. The other developer claimed I was essentially using a slippery slope argument to claim one thing will lead to another. But that’s just it, that’s the point of the broken windows theory.  He also suggested that he could track the windows and step in before it got too out of hand. I’m not so sure you can easily change the development culture surrounding an application after so long.

In a previous blog entry I mentioned the benefits of trying to give more than you take in terms of design choices when working with another developer. I believe in the above examples the developer who was allowing the broken windows was doing so in an effort to give wherever he could, an admirable thing to do.  To keep the metaphor going, one might argue that he had to give up a few broken windows so he could gain a few steel doors. Is there risk that the broken windows will lead to more problems?  Yes, I think it was even proven. However, as I have often stated before, it is also nearly definite that the hardest thing about software development is “other people”.  Sometimes a few broken windows are required to maintain goodwill and a productive development culture among those people.