Ask HN: How to avoid over-engineering software design for future use cases?
Something I&#x27;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 &#x27;60s and &#x27;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&#x27;ve met completely ignore in favour of the
superstitions, personal opinions, and catchy slogans that came out of the &#x27;90s
and &#x27;00s. It&#x27;s common to dismiss the early software engineering approaches with
&quot;waterfall does not work&quot; – as if the people in the &#x27;60s didn&#x27;t already know
that?! Rest assured, the published software engineers of the &#x27;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&#x27;s just nobody
teaching this knowledge – you have to seek it yourself.