3 ms·
Ask HN: What are problems inappropriate for iterative solutions?
I just watched Gary Bernhardt's talk "A Whole New World" [1]. Two-year old spoiler alert: he introduces an editor and terminal that doesn'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.
To you, what are other kinds of technology that can be clearly improved upon, but not "iteratively" in the agile and lean software sense?
[1] https://www.destroyallsoftware.com/talks/a-whole-new-world
- hakanderyal 11y agoCrypto. You have to get it right, and get it right at the first time.
- deleted 11y ago[deleted]
- thehickmans 11y agoAccounting/record keeping/informatics systems, industrial controls - anything that would lead to a catastrophic loss of some kind.
- sheepmullet 11y agoYep, 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.
- sheepmullet 11y agoAny 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.
- lsiebert 11y agoSoftware that will be used for a long period of time. For example medical devices, or vehicle parts.
- sheepmullet 11y agoAnything 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".
- mindvirus 11y agoWaterfall 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.