David Heinemeier Hansson 30 Sep 05

As a follow-up question: How did you take it slow to go fast today?

I’ll start: I pushed all the many Rails’ scripts in script/ down to the framework, so they could all be access through a single script/run portal. That made it such that I didn’t have to replicate changes across Backpack and Writeboard 3+ times a day. Now I just update to the latest Rails and both apps get the latest commands.

jean zaque 30 Sep 05

there’s an old saying in latin: Festina lente - Make haste slowly

Stefan Seiz 30 Sep 05

Father cow and son cow are standing on the hill.
Son says: Pa, look down there - see all the beautiful cows? Let’s run down and fuc* one of them.
Father cow: no son! Let’s walk down and screw them all ;-)

Dave Churchville 30 Sep 05

Great post, I try to operate this way too.

Otherwise you just wind up accumulating technical debt until your project’s credit card is maxed out.

To answer your followup question, I apply this principle to feature requests from prospective customers. Instead of blindly adding a feature request to the next release, to possibly get a sale from a specific customer, I slow down and wait for things to settle.

Usually the feature request is a more general issue, and when I finally do implement something, it applies to a broader group, not just the person who requested it. Not only does this make my product better, it keeps it clean and simple, instead of cluttered with one off “just this one thing would make it perfect for me” features.

DaveMo 30 Sep 05

Right on.

I used to ask my pushy boss, “Do you want it done right, or do you want it done right now?”

Guess which option he took, and then guess why I quit that job, and then guess why his Errors and Omissions insurer dropped his ass.

Paul 30 Sep 05

crap.

now I have to do it the right way AND in 4 hours.

i’m going back to wireframes and paper prototyping. at least no one can tell if those work or not…

Ryan 30 Sep 05

I only partially agree with this theory. There are a lot of places where the business WILL slow down and let you complete the unfinished work. Many companies’ business is seasonal and driven by external factors. An online retailer needs to be ready for a rush of Christmas customers, but can be confident that sales will let up a bit in January and February.

My current project is an online service that’s also very seasonal, used heavily in the summer. We had to rush to get a few things completed before we went live in May. Of course there was a trade-off between “done right” and “done right now.” But when we negotiated that trade-off, we made it clear that we couldn’t *eliminate* the work, we could just postpone it in order to launch on time. Now that things have slowed down, we’re taking the time to clean up some of the inelegant hacks we had initially made. Maybe I’m unusually lucky to have such enlightened customers, but for us, this has worked reasonably well.

I’m sure this won’t work well for everyone. If you’re a very small shop or an independent software vendor, I wouldn’t rely on this. But with the right negotiation and the right commitment level, this strategy *can* succeed.

Jason Watts 30 Sep 05

A frequent cliche out of my mouth at work - “There is never enough time to do it right, but there is always enough time to do it over.”

MH 30 Sep 05

Doesn’t this conflict with the “get sometthing out the door now” philosophy?

Matt Lyon 30 Sep 05

Jason W. said: �There is never enough time to do it right, but there is always enough time to do it over.�

Seth Godin has a nice collorary:

…if you don’t have the time to do it right, there’s no way in the world you’ll find the time to do it over.

Deirdre Saoirse Moen 30 Sep 05

My early experience as an aerospace programmer suggests that if you don’t take the time to do it right, you’ll never get a budget or window for a second launch. Fortunately, I never needed one.

It’s a sentiment that is as applicable to a small software house as it is to aerospace, really.

No big-upfront-design doesn’t mean no design. Once you’ve got the initial design, being mindful of what you expect to be in the future does help prevent unnecessary major refactoring.

After all, if you didn’t want to do it the first time, you sure won’t want to do it later.

Sometimes, I reward myself if I’m doing a task that seems odious: “Deirdre, if you finish this and it passes all its tests, why don’t we go out to a movie?”

David Heinemeier Hansson 30 Sep 05

MH: Nope. Instead of doing a half-assed job, just do half. Always pick less when given a choice (and MAKE it a choice when not given).

Anton Borzov 01 Oct 05

another proverb: “I have no time to sharpen my saw”

Point Taken 02 Oct 05

This assumes success is only predicated on good time management. What about making sure you’re even working on the right problem to begin with.

Nigel Thorne 03 Oct 05

I agree with ‘don’t live with broken windows’.

You can view ‘broken windows’ as a code debt. All the time the ‘windows remain broken’ you end up paying interest on that debt, and every piece of functionality that you add makes fixing the broken window that extra bit harder.

It is ok to leave windows broken for short periods as long as everyone involved in the decision knows there is a cost involved. By highlighting the cost the business can then make an informed business decision.

Thanks for helping highlight the cost of leaving windows broken.

asfd 06 Oct 05

asdasd

Don Schenck 07 Oct 05

I’ve been accused of being an “artist” because I “want to make the code beautiful”.

I take that as a compliment.

Buck up. Stand up to pressures. Push back. Folks, life is just too short to bend to every pressure that comes your way. Better to say “No!” and get fired.

I coward dies a thousand deaths; a brave man, only one.