It Doesn’t Take That Much Longer To Do It Right
April 13, 2009
One of my personal and professional mantras is, “It doesn’t take that much longer to do it right.” Sure, you can always do a half-assed job on some project just to shove it out the door, but there are inevitably down-stream costs. Whether it’s time lost having to go back and fix your broken junk or customer frustration and negative perception, your short-cut decision usually ends up costing you more in the long run.
Of course you know I have a story to illustrate this principle. During the peak of the dot-com boom I was helping a small start-up company move out of their sub-lease arrangement into their new permanent home. The weekend of the move, we had contracted with a moving company to do the physical move of all the equipment and personal items and I was helping the IT team for the company do the setup, server room build out, telephony configuration, etc. The building we were moving into was a two-story affair, and the plan for the equipment that was moving onto the second floor was to arrange it on pallets, wrap the pallet securely, and forklift the pallets through a second-story window. Pretty standard practice, actually.
The moving company, however, had negotiated a fixed-price bid. So it was in their best interests to get the work done as quickly as possible. Without our knowledge, they decided to throw caution to the wind and not wrap the palleted equipment. Sure enough, the first pallet went up on the forklift and as the pallet was moving forward through the window, one of the computers toppled off the edge and fell a full story onto concrete. The punchline is that the computer belonged to the office manager for the company and was the computer that was going to cut the check to the moving company. We were actually able to recover the hard drive from the twisted chassis and boot it in another PC, but the moving company had to pay a significant penalty that more than erased any savings that they might have achieved from not wrapping the pallets. Also, after that incident, we made them stop and wrap all the pallets anyway, which cost them even more time.
Once the equipment was loaded in, the IT team and I could get started with our part of the project. And it was a big project: from our Friday evening start to late Sunday night, I think we got maybe 12 hours of downtime to sleep. But there we were Sunday night and everything appeared to be ready for business to resume Monday morning.
Exhausted, but feeling pretty good about ourselves, we were standing admiring the new server room and somebody pointed out that we forgot to put the covers back on the cable raceways. There was a collective groan. We were “done”– surely replacing the covers could wait until the following week when we were all less tired? But when we all looked each other in the eye, we knew that the upcoming week was going to be so chaotic that if we put off doing it now we’d never get around to it in a timely fashion. So, without a word being spoken, we all grabbed some covers and spent another half hour or so fitting them into place.
When the execs toured the facility the following morning, we actually did get some compliments about how “neat” and “professional” the server room looked, but I don’t think that’s really why a crew of exhausted geeks spent an extra half hour re-assembling cable raceways. Nor was it because we’re anal retentive or budding masochists. I think it was because (a) we wanted to establish a culture of “doing things right” in the new server room so that entropy wouldn’t set in so quickly, and (b) we knew that going back and fixing the problem later would take longer than doing it right then.
So when you find yourself looking for excuses not to “finish” a project and just “get ‘er done”, take a moment and think about whether expediency is really the best policy. Remember that bugs are always cheaper to fix in development than after the product ships. It doesn’t take that much longer to do it right.