At the risk of going off topic, I want to respond to this: "Perhaps as a consequence, we’re swimming in acronyms, magic metrics, and methodologies, but not a l

At the risk of going off topic, I want to respond to this: "Perhaps as a consequence, we’re swimming in acronyms, magic metrics, and methodologies, but not a lot of rigorous systems thinking." I've said this before, but I want more developers to write honestly about their day-to-day experience in the trenches. The real life experience is often something quite different than "rigorous systems thinking." The whole industry would benefit if we had more honest accounts of the kind of bad management, and process chaos, that leads to high levels of tech debt. Many projects fail outright, but we don't get many good postmortems on the absolute failures. Of course, most of us sign NDAs when we join a company, so we need to step carefully if we later decide to pull back the curtains and reveal "This is why that project was such a disaster." Sometimes we have to change people's names, so we can speak freely. But again, I think the industry would benefit from this. It's what I was aiming for in my book How To Destroy A Tech Startup In Three Easy Steps, and I think the reason that book has become popular is because people appreciate the raw honesty. I do think we benefit from good essays that remind us how "rigorous systems thinking" might actually lead to better development processes, but such a theory of ideal development needs to balanced by the many factors that lead to pure chaos in many projects.