Absolutely agree. People made the bad decisions. But the bad choices existed. People who don't understand the bad choices are bad choices, or worse, think that there is no possible way there is a bad choice, are far more likely to end up being those people who made bad decisions then people who understand that the decisions mattered.

Don't go running around telling people that they can dig the Panama Canal with three toothpicks and a spare weekend, and if they fail, well by golly they just didn't have enough grit and gumption like us awesome folks who could have done it with only two. Tool choice matters. In fact I can hardly process how anyone can be an engineer and think that it doesn't, let alone how they can think it's some sort of engineering wisdom to claim that it doesn't matter what tools you use to do a project.

Of course, picking the tool is only the moment the project may fail. It is not the moment the project succeeds; there's still a lot of using it correctly that will be necessary and plenty of further opportunities to fail even with the correct tool. But at least success is within the range of possibilities. You can forstall that possibility entirely on day one with incorrect tool choices.

Sure, people with ZERO enterprise experience might say - hey, let's write our <main software> in PHP - I had a lot of fun 15 years ago with that, and I'm sure we can make it work.. That's the "3 toothpicks" in your example.

But is anyone REASONABLY competent going to do that? They might pick C/C++, Go, Rust, Java, etc. Those aren't a choice between "bulldozers and toothpicks" - they are more akin to choosing between Caterpillar, Volvo or Hitachi as the vendor of choice for construction equipment. They may have some gaps in their specific list of equipment, they may charge too much for one specific tool, your workers may have experience with one, not the other, etc..

Your example should be the textbook definition of a strawman argument..

> Tool choice matters. In fact I can hardly process how anyone can be an engineer and think that it doesn't, let alone how they can think it's some sort of engineering wisdom to claim that it doesn't matter what tools you use to do a project

Just to be clear, I wasn't trying to claim this; tooling certainly matters, at the very least, for the happiness and welfare of an engineering team! But, the article tries to claim things like "choosing a programming language is the single most expensive economic decision your company will make" and outside of a few extreme edge cases, I just can't agree with that particular thesis. Even the examples of bad decision-making you pose in your sibling comments, like writing a database in Go or "almost failing" by using sketchy niche datastores, are actually examples of this exact thing: these projects made huge engineering mistakes only to achieve some level of success as a business. Would they have been more successful if they made better engineering decisions? Possibly, but again, language and framework just was not the most important decision or factor driving an outcome.

I'm not saying that means we shouldn't care about making good engineering choices; there are easy ways to do things and hard ways to do things, and certainly I'm going to advocate for and work with people and at companies that favor the easy ways to do things. But when it comes to overall outcomes, I'll stand by having seen far more projects sacrificed to analysis paralysis, rewrites, rewrite-related hand wringing, and language/tooling hubris than sabotaged by poor language and framework choices.