Go Slow to Go Fast

#1

Post by craigkerstiens » Fri, Dec 30, 2011, 6:32 PM UTC

Re: Go Slow to Go Fast

#2

Post by ams6110 » Fri, Dec 30, 2011, 6:56 PM UTC

In 2011 I started doing some independent consulting/dev work to supplement lagging employment income. I found that this works pretty well, that is, always having a couple of projects in the queue. If I get stuck on one or just sick of it I go to another for a while. I've not managed to avoid deadlines entirely, because my clients have deadlines of their own. But the pipelining concept is a good one.

Re: Go Slow to Go Fast

#3

Post by the_cat_kittles » Fri, Dec 30, 2011, 7:37 PM UTC

"Start slow to finish fast" has been my motto for many things. It helps me avoid making mistakes at the beginning that I have to go back and change everything to fix. It also helps me avoid missing details that would make life easier.

Re: Go Slow to Go Fast

#4

Post by sn0wright » Fri, Dec 30, 2011, 7:56 PM UTC

the_cat_kittles wrote: post #3

"Start slow to finish fast" has been my motto for many things. It helps me avoid making mistakes at the beginning that I have to go back and change everything to fix. It also helps me avoid missing details that would make life easier.

I find it very similar to the motto I follow when jogging (and also what I"m trying to apply to other things): keeping a steady pace. By keeping a pace, you don't burn out towards later stages.

Re: Go Slow to Go Fast

#5

Post by InclinedPlane » Fri, Dec 30, 2011, 8:50 PM UTC

Bad code is a time and money sink.

The biggest mistake most companies make is not rushing bad code out the door too quickly, that's hard to prevent entirely, but rather failing to take the time to fix or replace bad code quickly once it's obvious the functionality isn't throwaway.

Re: Go Slow to Go Fast

#6

Post by akg » Sat, Dec 31, 2011, 12:13 AM UTC

I think there is an unbalanced amount of effort and enthusiasm spent these days on development methodologies: agile, waterfall, what-have-you. I think the thing that makes or breaks a product is the customers; and customers don't care if your product is well made, they just care that it solves their problems.

As long as you are moving forward (even if it is by inches) you are doing fine. A shipped working product that solves an important problem is better than a late unreleased one that tries to do everything.

Re: Go Slow to Go Fast

#7

Post by hopeless » Sat, Dec 31, 2011, 12:15 AM UTC

Only today I was thinking how agile "sprints" are the wrong terminology. No one wins a marathon by running back-to-back sprints. I know it's only terminology but I think it affects our approach and in practice can encourage a Continuous Death March instead of the intended manageable workload.

Re: Go Slow to Go Fast

#8

Post by jodrellblank » Sat, Dec 31, 2011, 12:27 AM UTC

A well developed cloud app allows for transparent updates without an acceptance loop from the customer.

This has a certain feel of spin about it.

Re: Go Slow to Go Fast

#9

Post by scottschulthess » Sat, Dec 31, 2011, 12:31 AM UTC

Great article.

Unreleased code is a liability and branches are a waste of time. If you're not deploying every day you are doing something wrong.

Re: Go Slow to Go Fast

#10

Post by scottschulthess » Sat, Dec 31, 2011, 12:32 AM UTC

InclinedPlane wrote: post #5

Bad code is a time and money sink. The biggest mistake most companies make is not rushing bad code out the door too quickly, that's hard to prevent entirely, but rather failing to take the time to fix or replace bad code quickly once it's obvious the functionality isn't throwaway.

How is that relevant to the OP?