I rather think it's both. We need better tools, and we need to become more professional.
The central tension in most of these articles seems to be thus:
Those two positions are irreconcilable. So, we subdivide "we" and say "It was a requirements problem" or "It was a process problem." This is a cop-out, IMO.
If you look at software development over the past 80 years, it's been a constant move towards better tools:
What's sort of interesting in the above is it's the history of limiting ourselves. We no longer re-wire the hardware, we write programs on general purpose CPUs. We no longer use GOTO; we structure control flow.
Why do that? Isn't the lower-level stuff more powerful?
Sure it is, but it's also running with scissors.
I feel like right now, with the re-emergence of FP and true immutable, message-passing like in Erlang, things might just be getting more stable. Complexity is going up, but if we build out of atomic, encapsulated units that are themselves well-tested, reliability and fault-tolerance should increase.
I'm on the record as being no particular fan of Uncle Bob. His approach is off-putting, strident, and self-referential. You failed because you weren't "good enough" or "strict enough." This stinks of "XP fails because you weren't XP enough." Let's get past that, okay? Waving "Clean Code" around like scripture gets you nowhere, particularly with management or customers.
That said, he makes good points. If we're honest with ourselves, as a profession we absolutely slip everything to make schedule. We do what's needed to be done, often because we under-estimate.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.