We don’t have time to do things right.

Buffer

Everybody working in software development in one way or another has heard this at some point: it would be really nice to do things the right way, but right now we’re busy, there will be time to fix the problem later on.

Later on, nothing happens. There’s never a moment when you’re less busy, when the bills don’t need to be paid, when work doesn’t need to be done.

Paint the mental picture of a cross country road trip. You need to get from San Francisco to New York, but you don’t know how to drive. You are still in a hurry to bring that car to the other coast, so you do your best and start piling up miles.

No matter how many times you crash and scrape the paint, no matter how many people honk at you, you keep driving because you have to go. Stopping now and taking driving lessons would be madness, right? So you keep driving, and your car gets beaten up more and more, because there’s no time to learn how to drive.

You might not make it to your destination, and still you don’t have time to do it right.

If this ever happened to you, or your company, there’s something very simple you can do: STOP. Take time to improve your processes. If there’s a skill your team needs to learn, make it part of their daily grind. If you’re using a bug-tracker to manage a project, go out and get a decent tool. If you’re not using a continuous integration server, get Hudson for free.

When you’re doing something wrong, the time to fix it is always now.

By Luca Candela

Born in Italy, after a MS in Computer Science in Torino, Italy, I moved to Madrid first, then to California to pursue my dream of working in the epicenter of the digital revolution, the Bay Area. I'm currently the Head of Product Management at Treasure Data. I'm passionate about Agile development, User Experience and social media. In the rare occasion when I'm not working, I like to play electric guitar, ride my mountain bike and enjoy Asian food.

6 comments

  1. Very true. But have you heard about the Pareto principle. How do you know when something is 80% or good enough? I feel the most difficult part is not "getting stuck" in optimising things that you feel matters, but maybe in the grand scheme of things doesn't really really matter..

    I'd love to hear your thoughts about this.

    1. I use a simple heuristic: would I feel ashamed showing the current state of the product to a new member of the team? Would he understand what has been done?

      If it takes you more time to figure out how to hack the system to include a feature or to fix what's not working, then it's time to take a step back and clean things up a bit.

      While it's easy to think you need "that special feature that will make all the difference", customers rarely care that much, but loathe to use stuff that works badly, or inconsistently.

      Speed, polish and simplicity always trump full-featuredness.

  2. Jeff Atwood (Coding Horror) wrote a really interesting article on "technical debt" a while back. (I won't spam you with a link). His premise was it's inevitable, but just as inevitable, if you don't pay it (i.e., maintain your code), it's all going pear shaped.

Leave a Reply to Magne Matre Gåsland Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.