amandavinci

Ideas must change in response to feedback from the problem to be solved.

The initial idea and its nth iteration are downstream from the real problem. What matters, therefore, is the iterative execution of those solutions. So instead of basing our judgment on the quality of the idea, we should rely on the execution ability because that is fairly constant in the development loop.

If you end up on the far-side of an idea-driven development process, you'll have solutions looking for a problem.

We don't build software like a bridge; we grow it like a garden. The industrial revolution was about building machines that dominate its environment. The software revolution is about writing code to resonate with its environment. The software grows in harmony with its user and business needs. Except, of course, for special cases such as this.

"The whole approach to developing software is intentionally designed not to rely on any particular person."

Our programming culture is not ready for this. Any programmer who identifies with their craft will never want to be another cog in the machine. A programmer could have chosen to be a doctor, lawyer, engineer, etc. but they choose to code because it is one of the way they can "express" themselves.

The analogy of maps and boats is just an instance of the exploration-exploitation idea. I have seen instances of this pop up every time we discuss problem solving in some form. It falls in the perennial variety of ideas that can't be revisited enough.