
Go Slow to Go Fast - craigkerstiens
http://onticoren.com/go-slow-to-go-fast
======
hopeless
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.

~~~
_dps
I wonder whether there's some hidden wisdom in the terminology. Agile
"sprints" are (in the folk-wisdom) ideal for getting somewhere quickly
precisely when you don't know where you want to finish. In this case a "quick
sprint, rest, reorient, sprint again" metaphor seems appropriate.

On the other hand, long-running maintenance work with a stable goal over a
year or more probably benefits much less from sprinting. I guess in this case
we would need to know what "marathon" development would be :-)

------
InclinedPlane
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.

~~~
scottschulthess
How is that relevant to the OP?

~~~
InclinedPlane
The OP extols the virtues of releasing code "when it's ready" due to the
hazards of rushing code out the door in an "unready" state. Unready means bad.

~~~
scottschulthess
ah yes I agree

------
ams6110
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.

------
the_cat_kittles
"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.

~~~
sn0wright
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.

------
akg
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.

------
jodrellblank
_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.

------
scottschulthess
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.

~~~
aytekin
The best way to branch seems to be to release the code but hide it with a
switch so that only developers can see it. This way, when you release the new
feature, all you are doing is enabling it for everyone else.

------
mkramlich
I've found that, as a general rule, there's no such thing as actual deadlines.
Or rather, actual deadlines are rarer than supposed ones.

One common excuse for a particular ostensible deadline is that it is due to
some _other_ , downstream/outside deadline, perhaps on the customer or
stakeholder's side of the fence. But even then, very often, that entity's
deadline is not really a deadline, it is typically yet another date pulled out
of thin air because it sounded nice, regardless of whether it was realistic. A
guess added to another guess added to another guess which get summed up and
padded and turned into an estimate then pegged to a date then ever after
referred to as a "deadline" (cue ominous music.) We come up with deadlines
because we like to have certainty and the myth of control over things where in
reality there's quite a deal of uncertainty and quite a large number of things
over which we have no control. Deadlines can be good as goal dates associated
with certain milestones, but even then it's best to call them that and treat
them as such. I've seen too many software industry deadlines where teams
worked like keyboard slaves to ship a particular feature set by a particular
date, and ALMOST ALWAYS in the cases where the date wasn't hit there were NO
significant negative consequences, no heads rolled, no business lost, etc.,
just a pleasant _whooshing_ sound as the date flew past, and a quiet
rethinking on the part of every developer who just took part in that "false
alarm" march.

I've also noticed that, at least in the software industry, that deadlines are
common when Project Managers are present. But PM's are, in my opinion, a bit
of an anti-pattern themselves. Not that all PM's are bad -- because some of
them are good and helpful -- but rather that if you're in a situation where
you think you have to have a PM (or a deadline, or both) then that's usually a
consequence of something else being wrong about your organization or process,
and so you might be better off fixing those root causes instead.

~~~
ams6110
In some situations deadlines, even if pulled from thin air, are at least
something to focus on to get the project _done_. I've been on projects with no
real deadlines, and they seem to meander forever and never actually get done.
Finally someone will put a foot down on a date and magically everybody gets
things wrapped up.

~~~
mkramlich
agreed! which is why I said this:

> Deadlines can be good as goal dates associated with certain milestones, but
> even then it's best to call them that and treat them as such.

