In four words you managed to perfectly encapsulate the problem I have with so much writing about development processes and tools.
It's not good enough to claim to be just incrementally better than what you're probably doing, you need to be the best most super awesome EXTREME thing ever!
The 1-star reviews roughly fall in three categories:
- This is not how proper projects are done.
- We don't need another cult-like methodology
- This will vindicate cow boy coders
The real problem with cowboy coding is getting to version 2 (or maybe 1.1). But it should be stated that at least if you've got a successful version 1 you have most of a solid design to start with.
Interestingly, most development methodologies seem to be mainly concerned with getting to version 1 and not with producing a maintainable product or getting a successful but unmaintainable version 1 and evolving it into a maintainable version 3 (say).
The obvious exception is the Software Process Maturity Model or whatever the frack it's called today, which is enormously concerned with maintainability to the point of making initial development (or indeed almost anything outside of pure engineering environments) virtually impossible.
In all seriousness, yes, different methodologies are certainly good for different organizations and different projects, and you're right that cowboy coding is effective at getting things done. I've definitely seen organizations that weren't well-suited to traditional methodologies get mired in documentation and fail to get anything out of alpha. Whatever approach you choose, just don't follow it straight off a cliff.
I lived in that world on a DoD program for 3 years. I still have nightmares.
We also had a customer who didn't want to "pay for the same code twice". That meant signal processing algorithm research had to be done in the operational real-time code, and that we could have one and only one codebase (including branches but not including engineer/scientist working copies). The "experts" from Mitre and elsewhere who were managing us were so clueless they didn't realize this was costing them more and adding more risk than allowing the scientists to do their algorithm development in Matlab and Fortran, then have the engineers turn the algorithms into an operational system. Of course, we still had to have requirements and design documentation up-front before we could implement code, so...
It may be related to the dark world as well, but it seems to be waning.
...was in fact a strawman. The whole horrible waterfall process was an urban legend: http://postagilist.wordpress.com/2012/06/13/the-perennial-wa...
Bullshit.
Source: I lived through it in the early and mid 1990s.
However there is hope. www.gov.uk is a notable recent success story. https://www.gov.uk/service-manual/agile
The difference is that in the early 1990s, most of us thought that larger software projects were just like that. We didn't know any better.
Not only are there projects where waterfall methodologies were applied, but they are sometimes (gasp!) appropriate.
In the majority of cases, iterative development of some sort is necessary, because the requirements keep changing. Waterfall simply doesn't allow for changing requirements, so it's hopeless in those cases.
But where requirements are stable, waterfall is a reasonable approach. Remember, it had its origins in the big iron days, when vast project teams analysed and replaced existing manual systems. For those projects, waterfall worked.
If you're writing the code for a space probe, or a missile, there's a limited opportunity to iterate once the item is deployed... requirements are stable, waterfall can be a rational choice.
And on moonless nights I still wake up screaming remembering a RUP project I was involved in around 2000.
"No true scotsman" and all, I know.
https://plus.google.com/+LaurentBossavit/posts/VBJTGru3PeW
Or this.
Which was a gross misinterpretation to this day. We still have naive PMPs running $100 million IT projects in the faux-Waterall style.
This school has its agile proponents too, though. But compared to the common practices of the penultimate decade, XP and Agile at least acknowledged that failure was the default mode of software development projects, and made contingency plans for it.
To me it felt like they were saying, "You know all the things you did to make your last project a huge success: the short iterations, tight feedback loops, early and frequent customer involvement, designing your systems to accommodate change? Yeah, don't ever do any of that again."
So I left, and found that dogmatic by-the-book scrum shops can also be horrible places to work. Live and learn.
Absolutely. If the waterfall isn't working, you need to waterfall harder. Because more time spent up front writing paper architectures and guesswork requirements is what's needed!
The criticisms about no metrics supporting the book assertions are valid too (we have more metrics now, though).
That said, a lot of things in this book are now considered good engineering practices, and the methodology guys have come back with a vengeance with the Agile/Scrum/Lean/Whatever waves that filled the blanks left by XP (and ensured a nice revenue stream for pure process consultants).