Uncle Bob and Silver Bullets

Robert Martin's best known open source software contributions are for FitNesse, which is reasonably well known in the testing world. https://en.wikipedia.org/wiki/FitNesse

Tell me, have you read the Space Shuttle control software? There are dozens of not hundreds of papers about NASA's development process. Are you saying that since you can't look at it, you're not prepared to take their word that the software is successful?

Because it seems to me that there are other ways to judge success than simply reviewing the code.

The problem is that the business tend to drive the "if it compiles, ship it culture" but also want to blame some lowly replaceable coder for any mistake so the organization and it's leaders can avoid any responsibility for any damage done due to their decisions to ship first and test later.

And Bob Martins post seams to cater perfectly for that sentiment, of never blaming the CIO/CXO for demanding the impossible, and overruling concerns but laying the blame entirely on the lowest and least powerful link in the chain.

People tend to forget that shipping despite warnings from a formal test suite, is baiting an audit failure in a way that overruling concerns voiced by actual people.

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.

I don't think so... No one's hunting down and calling to account the engineers responsible for the Equifax breach, and nor should they. The problem is blatantly a leadership and resource-allocation issue, and is being treated as such.