Summary
In software the race goes to those who go well, not those who go fast.

Have you ever been to a tractor pull? Imagine a huge arena filled with mud and churned up soil. Huge tractors tie themselves up to devices of torture and try to pull them accross the arena. The devices get harder to pull the farther they go. They are inclined planes with wheels on the rear and a wide shoe at the front that sits squarely on the ground. There is a huge weight at the rear that is attached to a mechnism that drags the weight up the inclined plane and over the shoe as the wheels turn. This steadily increases the weight over the shoe until the friction overcomes the ability of the tractor.

Writing software is like a tractor pull. You start out fast without a lot of friction. Productivity is high, and you get a lot done. But the more you write the harder it gets to write more. The weight is being dragged up over the shoe. The more you write the more the mess builds. Productivity slows. Overtime increases. Teams grow larger. More and more code is piled up over the shoe, and the development team grinds to a halt unable to pull the huge mass of code any farther through the mud.

Our industry is addicted to speed; and it's killing us. As we leap out of the starting gate on a new project, if we focus on speed over quality, we sew the cause of our eventual defeat. As an industry, as a profession, we need to seriously re-think the way we do software. In software, speed kills.

The way to go fast, is to go well. Going well means taking time to keep the code clean, to write tests, to refactor, to take care of the code. Going well means taking a deliberate and caring attitude for the code, and the system. Going well means working as a team, communicating frequently, reviewing and inspecting code and designs. Going well means never checking in code that fails unit tests or acceptance tests. Going well means integrating frequently, at least once per day. Going well means staying rested.

There is always time to write tests. There is always time to refactor and keep the code clean. There is always time to review and inspect and pair. There is always time to integrate frequently. Indeed, there is no time not to do these things, because these are the things that keep us going fast. These are the things that keep the weight back over the wheels rather than over the shoe. These are the things that keep our productivity high, and our code flexible and malleable.

Over the years I've published a lot about design principles, design patterns, and development practices that can help teams keep their code clean and flexible. However, these principles, patterns, and practices are only of use to the folks who take the time to use them. Interestingly enough, these are the same folks who will get done faster, and better, than those who don't take the time. Those who don't take the time just keep dragging the weight up over the shoe.

The next time you say to yourself: "I don't have time to do it right." -- stop! Rethink the issue. You don't have time not to do it right!

Where did we get the idea that our companies wanted us to write crap? Aren't they paying a lot of money for this software? Aren't they going to depend upon this software for profits? Isn't this software worth a lot? If so, then why would our company want to pay for crap that slows us down? Wouldn't they rather have good clean code that keeps us running fast?

A few years ago I hired two apprentices. I gave them a project to do. They came back a day later and said they were done and asked if I'd like to see it. I knew this project should take more than a day, so I started asking them about how they had built the project. I asked them whether they had written tests, or whether they had separated concerns. I showed them alternate designs and different coding practices that were better than the ones they had used. They were incredulous. "We feel bad because you are paying us a lot and we want to get this done fast." they said. I explained to them that the software they were writing was intrinsic to my business, and that it was more important to me that it be done well, than done fast. I explained that if they didn't do it well, then they'd be maintaining a mess for years, and that maintenance would take much more time and energy than they'd saved by doing it fast. I told them to go back and do it well. And they did.

We often blame managers for schedule pressure. We often complain that our companies set unreasonable deadlines and have unrealistic expectations. This might be true, but it's only half the problem. The other half, the most important half, is within us. We consider our worth as programmers to be more associated with speed than with quality. And that's a tragedy; because it leads us to create messes. It leads us down the slower path. By rushing we ruin our chance to truly go fast.

I was with a team the other day, and the manager of the team said to them: "I want this code to be something you'd be willing to hang on your grandmother's refrigerator. I want it to be high quality. Remember, two years from now all people will see is the mess, they won't see how fast you got it done. Nobody remembers the speed, they only remember the mess. So do it right". The programmers looked at him skeptically. Their boss just told them to go well, instead of going fast, and they didn't believe him. What does it take?

Take my advice: go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills.

Talk Back!

Have an opinion? Readers have already posted 30 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Robert C. Martin adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Robert C. Martin (Uncle Bob) has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor Inc., a team of experienced consultants who mentor their clients worldwide in the fields of C++, Java, OO, Patterns, UML, Agile Methodologies, and Extreme Programming. In 1995 Robert authored the best-selling book: Designing Object Oriented C++ Applications using the Booch Method, published by Prentice Hall. From 1996 to 1999 he was the editor-in-chief of the C++ Report. In 1997 he was chief editor of the book: Pattern Languages of Program Design 3, published by Addison Wesley. In 1999 he was the editor of "More C++ Gems" published by Cambridge Press. He is co-author, with James Newkirk, of "XP in Practice", Addision Wesley, 2001. In 2002 he wrote the long awaited "Agile Software Development: Principles, Patterns, and Practices", Prentice Hall, 2002. He has published many dozens of articles in various trade journals, and is a regular speaker at international conferences and trade shows.