For all you detractors, here's my story, maybe it will help you believe that quality is possible in our industry.
I have been doing professional software development since 1997, and from then until two years ago, I have been a developer on waterfall and scrummerfall projects. There have been deathmarches aplenty and lots of failures small and large with some heroic successes here and there. Overall, I'd say the performance of the teams I had been on has been fair to poor, and the code quality has been generally poor because it was always rushed.
Then two years ago, my manager got on a quality kick and the team was largely with him because we were frustrated with some boneheaded defects that had escaped to production. First, we started to require some unit testing here and there, and code quality started to improve, at least to those of us on the team who noticed such things.
Next, we all decided on a new greenfield project that we would enforce a test-first/TDD rule. Our code coverage was suddenly obscene! Months later, we had no escape defects when we delivered to production on-time. No escape defects was unheard of in our division, and a point of pride for the manager.
The TDD we were doing was largely just a gentlemen's agreement, and there was little pairing. Mainly we all still worked in our little heads-down solo developer modes. So, manager decided to amp up the agile more. We got TDD training ("obey the testing goat" video series) and we became much more open to the idea of pairing. The QA team was fired, we ended up with one floating QE engineer. He occasionally pairs with us, developing for real stories. An agile coach came to visit us and gave some tips. Got scrummaster training, bleh ...
On the next project, also a greenfield, we were much more confident. Pairing happened very dependably whenever we did any new development. We were less intent on metrics such as coverage, and more intent on writing our unit tests like they were a software spec. Spock Framework for Java is a really nice system for doing this, our tests read almost like english paragraphs. Our defect rate is similarly low like it was on the previous project, but now we have a much better comprehension of the code. I feel like the whole team is communicating better and can understand the subtle design direction changes that naturally happen throughout the course of a project. We just completed our first story mapping exercise for this project, it's really neat to see our plans all laid out on the board like that and this has been very helpful for our product owner.
There's a lot wrong with our situation, but we're impatient to fix things since we don't have defects to mentally burden us constantly. A one-click build would be really nice, and our overall system design handed down to us from on-high is heavy-handed. We're so agile now we can usually devise a long-term plan to address our issues that everyone is comfortable with. Our product owner is struggling to get better definition around aspects of the project, but we make it possible for him to shift directions - again because the codebase is well-factored and largely free from bugs.
My main observation looking back on my 18 years of coding is that software takes a long time to write. It's really excruciating. Trying to turbo boost a project by overcommitting resources and doing death marches usually doesn't shorten the actual time to delivery all that much in my estimation, but it DOES drive up the risk because people are going to fail on you left and right.
This excruciating slowness to develop software has only become more evident to me now that I'm on a team that is genuinely trying to be agile. Every little feature and every task on the board is SOOOO drawn out and painstakingly developed by pairs of developers. DevOps is a big deal that saps tons of the team's time, but it is important for us to own this.
I just never thought I would see proper resource allocation to software projects, but here it is. My company is spending the money it needs to AND the management, product owner, and developers on the team are all willing to work this way. We took no shortcuts and focus on code quality. Effort put into documentation is fairly lite, unless it is intended for the user.
I can count on one hand the number of days I was asked to work overtime in the last 2 years.
The question I have is, if high quality software development is possible, is it a lot more expensive than the old death march/waterfall/lie-to-ourselves-constantly style of development? My team no longer has show-stopper production environment defects nor a QA department anymore. Surely that has to cut our costs a lot! We do have a dependable cadence, and have recently been seeing our velocity accelerate. While we do meet our product owner's goals, but I'd say our progress feels achingly slow at times. Maybe I'm just impatient or restless. I'll need to ask my manager if he can gauge whether we're more or less expensive to run than we were in the past.