[javajosh]

There is a strong analogy in software engineering here. Often the first implementation is "wrong" in the sense that it doesn't resolve the inherent tensions in the system. But that doesn't make it useless - in fact, it's quite useful because it actually showed you what is important. Plus, the people who attempt the initial solution to a problem deserve special honor, even if their work is eventually tossed away, specifically because they revealed these system tensions. The common dictum to "write a prototype and throw it away" is largely based on this insight.

What I'm saying is that Ptolemy, Aristotle, etc did a great service to humanity by taking a stab at hard problems, even if their solutions were convincing but wrong. Whether they knew it or not they were the primordial programmers writing a throw-away prototype upon which all future progress was based.

[QuercusMax]

I work on healthcare at Alphabet, and in late 2016 I set out to build a flexible DICOMweb STOW-RS receiver in the form of a GCP API - the first time anyone had done that at Alphabet. (I've worked on the same project across Verily and Google). In the process I researched and built a bunch of little prototypes built in a variety of ways, and for example had to rule out building it as an App Engine API - because DICOMweb uploads can potentially be gigabytes in size, and App Engine didn't support handling a POST as a stream as it arrived.

At any rate, along the way over the course of 9 months or so I found a technology stack that supported all my requirements and ran into a bunch of roadblocks. Lots of things related to how internal bits of GCP APIs are handled - the internal libraries had documentation indicating that streaming APIs were supported, and that each chunk of the request would be passed from the API proxy/backend multiplexer to the actual API server as they arrived. This worked for streaming responses, but not for streaming requests, and so I had to add that functionality to the API proxy. That was a huge pain - really hairy c++ code using fibers with multiple layers of request processing wrappers. But I worked thru that and got it landed into the google-wide binary, and never worried about it again.

I got this project to the level I needed it to support the precise requirements for the (regulated medical device) system I was working on. Around this time the GCP Cloud Healthcare group was getting started, and they built a new system using a fair number of bits of my implementation, which they'd eventually replace completely. But my first system saved them most of a year or work, resulting in the CHC feature set rapidly leapfrogging what I'd built.

[jyunwai]

A similar idea about the importance of planning as a way to improve your understanding of a problem was expressed by Dwight D. Eisenhower, said in a speech while he was in office as the US President in 1957 [1].

Reflecting on his experience in the Second World War, he said: "Plans are worthless, but planning is everything. There is a very great distinction because when you are planning for an emergency you must start with this one thing: the very definition of “emergency” is that it is unexpected, therefore it is not going to happen the way you are planning."

[1] https://quoteinvestigator.com/2017/11/18/planning/

[nonrandomstring]

Your software engineering example made this click for me. I think what we might be talking about is the method of abduction [0][fn]

[fn] not kidnapping, but a logical (procedural) method like induction or deduction

[0] https://plato.stanford.edu/entries/abduction/