Ask HN: How to avoid over-engineering software design for future use cases?
Something I've recently realised after having listened to Kevlin Henney talk
about software engineering is how much of the existing knowledge we ignore. The
early software engineers in the '60s and '70s were discovering pattern after
pattern of useful design activities to make software more reliable and modular.
Some of this work is really rigorous and well-reasoned.<p>This is knowledge most engineers I've met completely ignore in favour of the
superstitions, personal opinions, and catchy slogans that came out of the '90s
and '00s. It's common to dismiss the early software engineering approaches with
"waterfall does not work" – as if the people in the '60s didn't already know
that?! Rest assured, the published software engineers of the '60s were as strong
proponents of agile as anyone is today.<p>Read this early stuff.<p>Read the reports on the NATO software engineering conferences.<p>Read the papers by David Parnas on software modularity and designing for
extension and contraction.<p>Read more written by Ward Cunningham, Alan Perlis, Edsger Dijkstra, Douglas
McIlroy, Brian Randell, Peter Naur.<p>To some extent, we already know how to write software well. There's just nobody
teaching this knowledge – you have to seek it yourself.