This is unfortunately a very defensive article. The author would do better if he chilled out a bit. I get why he's defensive: Martin calls his baby out in his

This is unfortunately a very defensive article. The author would do better if he chilled out a bit. I get why he's defensive: Martin calls his baby out in his article. And, although I think that Martin himself comes across as defensive (he is alarmed that the journalists didn't interview 'real' experts like himself), I also don't think he is wrong. In fact, as a practitioner for over 20 years, I've witnessed first-hand the gradual degradation of software discipline. I've seen too many companies do exactly as Martin describes, and it causes many issues: from critical bugs to developer burnout. It's important to look at the root causes. I surely don't have all of the answers, but I do note the rise of the 'startup culture' as a major issue. Even at big organizations, employees are now expected to run projects using extremely low resources. The companies encourage this behavior saying things like, 'think of your program as a startup'. Startup is the new executive buzz word. Startups are obviously great, but they take on extreme amounts of risk. And, since people only see the survivors, they naturally make the (erroneous) logical conclusion that startups are silver bullets and have guaranteed return on investment. Therefore, every project should be a startup! And, with that, we see skeleton teams with huge responsibilities and expected return but a deficit in resources. Today, an engineering team of 4 people is expected to do the work of 16 people circa 1995. Team leaders accept this pain and manage it by sweeping issues under the rug. As a side note, it tends to cause people to be more unethical. The examples that the author uses (Amazon, Microsoft) are not representative of typical software organizations today. Amazon and Microsoft have huge amounts of resources available. They have veterans and researchers able to take things like TLA and apply them to real projects. They have the ability to manage their risk. But, a typical team is strapped for time and they must rely on tools to save them at the expense of software discipline. Anyway, my point is that investors want huge return on investment. This causes sales and marketing teams to over-promise and under-price. This causes delivery teams have to drive their projects with extreme risk. Extra people are too expensive, so just wing it. If you survive, maybe you’ll get to build it right the second time. If you fail, well rinse and repeat at the next place.