That’s such a good one! I wish more people understood this. It seems management and business types always want some upfront plan. And I get it, to an extent. But we’ve learned this isn’t a very effective way to build software. You can’t think of all possible problems ahead of time, especially the first time around. Refactoring to solve problems with a flexible architecture it better than designing yourself into a rigid architecture that can’t adapt as you learn the problem space.

That is a good one, iterative development is in general superior to overly deliberate and overly careful development.

And what a great and very subtle example with the fighter jet control sticks. This reminds of a build time issue I once had. Yeah, way back in college, did really poorly on a final programming project, because didn't realize you were supposed to swap out a component they had you write with a mock component that was provided for you - hard to explain, but they wanted you to write this component to show you could, but once you did, you weren't supposed to use it, because it was extremely slow to build. So they also gave you a mock version to use when working on the code of your main system.

Using my full component killed my build time, as it took 10 minutes to build instead of a few seconds, and it was the one school programming project I couldn't finish before the deadline and was super stressful. Was a very painful lesson but ever since have always found ways to shorten my build times.

I think taking Boyd's law to the extreme is how some folks end up with sprints lasting 1 week or less.

This resonates with "the bitter lesson" somehow, interesting...

...On reading more it seems of use primarily in adversarial situations, so not-so-much resonant.