

Ask HN: What are problems inappropriate for iterative solutions? - eric-hu

I just watched Gary Bernhardt&#x27;s talk &quot;A Whole New World&quot; [1].  Two-year old spoiler alert: he introduces an editor and terminal that doesn&#x27;t actually exist.  His thesis: that some pieces of software--specifically developer infrastructure--take long periods of dedicated thought (without user discovery) to improve upon.  Case in point: Clojure.<p>To you, what are other kinds of technology that can be clearly improved upon, but not &quot;iteratively&quot; in the agile and lean software sense?<p>[1] https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;talks&#x2F;a-whole-new-world
======
mindvirus
Waterfall style development (non-iterative) is appropriate for well defined
problems, where there are few unknowns. Here it makes sense to do the majority
of the planning up front, since it'll let you consider the design in its
entirety. The iteration here comes in the planning phase. Programming
languages and text editors are good examples of this - most surprises should
be caught in the design phase.

In contrast, where iterative development shines is where there's an external
feedback loop somewhere - this is the user discovery that you're referring to.
If you don't know what the customers really want, build something, give it to
them, and get feedback. The risk to iterative development though is that it's
gradient descent - it ends up converging to a local optimum but won't get you
to a global one.

Of course, very little development is purely iterative or purely waterfall,
but rather it's a spectrum. Programming languages and text editors have
version 1.1, 1.2, etc., after all. One of my annoyances with iterative
development is that it's often used as an excuse not to plan - so people end
up walking into problems that easily could have been known upfront, and
ultimately spend more time building a worse solution. Imagine building a house
- that the house needs plumbing should be something the architect realizes
upfront, not something that should be discovered half way through.

------
sheepmullet
Anything where stability is more important than features. E.g. I would be
incredibly angry if work paid me a few weeks late, or paid me significantly
less than they should, or couldn't process my leave, etc, because the payroll
processing software devs took the attitude of "move fast and break things".

------
sheepmullet
Any software where backwards compatibility is important requires a lot of
"thought" up front. Otherwise you end up supporting half baked solutions for
years.

I'm still supporting half baked solutions from 10 years ago because we don't
want to break our customers systems.

------
hakanderyal
Crypto. You have to get it right, and get it right at the first time.

------
thehickmans
Accounting/record keeping/informatics systems, industrial controls - anything
that would lead to a catastrophic loss of some kind.

~~~
sheepmullet
Yep, and if important (to the user) data is involved you better be super sure
you don't corrupt/lose it.

I'm still mad at Evernote for losing my data years ago and tell everyone I
talk to not to use it.

------
lsiebert
Software that will be used for a long period of time. For example medical
devices, or vehicle parts.

