

Martin Fowler: Is it worth it to design software well? - henning
http://martinfowler.com/bliki/DesignStaminaHypothesis.html

======
frossie
Summary: There is a design pay-off line - having little software design may
get you to market faster but then hampers you downstream; having too much
design slows you down for no additional payoff.

I call this the "less talk more code" point. Of course the trick is figuring
out where that point is without the benefit of hindsight. In my experience it
really helps to know what the shelf-life of the product is, and the length of
the future development cycles, which is not always clear in advance. I have
called "less talk more code" on a project thinking we would only need the
software for 3-5 years before having more time to refactor; if I had known we
would have been still using it 10 years later in its original state, my
determination of where the payoff line might have been different.

~~~
locopati
That seems like a common problem. You gather requirements which suggest that
the software will be used once or for a limited time, so you cut corners in
order to get it done quickly and then years later the software is still being
used and everyone is complaining about the cut corners without understanding
the circumstances by which they came to exist.

~~~
frossie
I agree with you, though I am not necessarily talking about "cutting corners",
which to me implies slopiness. It's just that you can optimise for a certain
environment of use, but if you don't realise that the software will be used 10
years from now, you don't worry about how the usage environment will change.

This isn't sloppiness, it's optimisation - as the old saying goes, the perfect
race car is the one that falls apart 10 yards past the finishing line; if it
lasts for longer it was overengineered. It's just that in software we don't
know where the finish line _is_ \- or even if there is one.

------
zmimon
I sort of agree with this but I also think it fails to mention the problem of
over-design: anticipating requirements that will never materialize or any kind
of thinking that goes too far ahead causes enormous cost. There's one thing
worse than no design, and that's the _wrong design_ (even if, when created, it
was a "good" design).

------
jwilliams
Design and project execution should be about taking on the key risks in your
project.

If you're a startup, the biggest risk might be 'is there a market for this?'.
In this case, yeah, maybe skip a lot of the design, get something rough-and-
ready to the market.

If you're a bank, your biggest risks are probably around reputation, security,
compliance, etc. In this case, you might do a lot of design around scalability
and reliability.

So I'm an advocate of always doing design - just make sure you focus on the
parts that count.

