I was a competitive swimmer in high school and college, so when my oldest daughter was old enough to learn to swim I made sure she learned how to swim well. I didn't want her, like so many young kids, to take a stroke, and then lift her head up to breathe. I wanted her to learn to breathe on her side. This proved difficult for her at first, but she learned to do it by rolling all the way onto her back, taking a breath, rolling back, and taking the next stroke. At first she swam much slower this way than if she just lifted her head to breathe. But, what was important to me was that she learn to swim well. I knew she'd gain speed as she learned to roll over just far enough to breathe.

When something is done well, it's only a matter of time until it is done quickly. This is true not only in swimming but also in software development. As software professionals-programmers, testers, and managers-we spend far too much time fixated on speed and asking questions about how long a task is likely to take. Instead of focusing on going fast we need to focus on going well.

I remember the last time I told a team to hurry up. I was managing and programming with a small team that was rushing to write a C++ system to replace the company's aging legacy system. We'd been at it for three months and had an important demo coming up. I distinctly remember telling the team to "hurry up." We met the deadline but we paid the price later when we had to fix the bugs that resulted from our focus on hurrying up. I learned from that and now I simply remind teams of deadlines or point out they might be in risk of not making a commitment. I always stress the need to write high-quality code more so than the need to meet a deadline.

With high quality code there are very few or no bugs. High quality code includes high quality automated tests. We use these tests to ensure that quality isn't transient; it isn't there in version 1.0 only to quickly go away as we change the code. With high quality code, it becomes easy to go fast. By going concentrating on quality we become able to go fast.

Programming Pride into Your Code
Some teams are uncomfortable with being told to do their highest quality work. Not only have we adapted to schedule pressure, we prefer it more than quality pressure. If I'm under schedule pressure and I find a bug, I can claim the bug was a result of the schedule pressure. After all, under normal conditions no one makes mistakes, right? Under quality pressure, I can't make such excuses.

Most or hopefully all of us have been involved in a project that was delivered on time. How many of us worked on a project that delivered quality code we were proud of? I'm talking about the type of project that when it's finished, you can hold up the code and say, "I'm proud of this."

Try this exercise: Either at the end of your next iteration or next Friday (if you're not using an iterative process), ask everyone on the team if they performed their highest quality work. See how many answer yes. If the question is uncomfortable, have everyone put their heads on the table and close their eyes before asking it. Even if I've been stressing the need for quality rather than speed, I would never expect everyone on a team to answer yes to this question. What's eye-opening is how often no one on the team answers yes, even though they've been told to focus on quality rather than schedule.

The Refrigerator Test
Think back to when you were a young child in school. When you brought home a drawing or a test you were proud of, your mom would hang it on the refrigerator. The drawing or test may not have been perfect but you had done your best. You and your mom were justifiably proud of it and so it was displayed on the refrigerator for everyone to see.

Write code you'd be proud to hang on your mom's refrigerator. Make it your goal to always write the highest-quality code you can write, and I'll suspect that you will quickly become a faster programmer.