Hacker News Reader

Comment by abolibibelot | Hacker News Reader

Some of the criticisms are still valid: there's a definite "gossip magazine diet plan" vibe to the book, even if the clean cut from waterfall or iterative process horrors (Rational Unified Process anyone?) was sorely 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).

View on HN

gossip magazine diet plan

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!

I wish I had coined the term, but it's taken from an actual comment: http://www.amazon.com/review/RDZBBO2Q4MI6V/ref=cm_cr_pr_perm...

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

2 and 3 may have a point.

I've seen a lot of cowboy coders get projects done. (I've probably been one for a good deal of my career.) Can you say that with a straight face about adherents of more rigorous development methodologies?

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.

Who needs a maintainable version 3 these days? If your product hasn't been acquired and shut down by that time, you've failed. :-P

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 think the EXTREME branding hurt corporate adoption.

> iterative process horrors (Rational Unified Process anyone?)

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...

This is one of the reasons if I see anything "rational" about a job post I ignore it

Wise policy. I keep getting tempted by that dark world, though. The subject matter I was working on was awesome (real-time radar signal processing) and I had a great 60/40 balance of EE/CS knowledge focus. I can't find any jobs like that out in the real world, though. Everyone out there seems to want either a CS expert or an EE expert, not a hybrid.

You may try some embedded devices work, there's a nice mixture of EE (for when things don't work, usually) and CS

It may be related to the dark world as well, but it seems to be waning.

> the clean cut from waterfall

...was in fact a strawman. The whole horrible waterfall process was an urban legend: http://postagilist.wordpress.com/2012/06/13/the-perennial-wa...

> The whole horrible waterfall process was an urban legend

Bullshit.

Source: I lived through it in the early and mid 1990s.

I'm living through it RIGHT NOW. I'll give you one guess who pushed it on us. And I'll even give you a hint: it almost rhymes with "rubbermint".

It happens outside government too. It happens anytime your higher-level boss tells you: "Yes, I'm on board! You're right, a system like that would help us tremendously in several ways! Please estimate the costs for it so I can get us the money in our budget meeting next month." Happens all the time in enterprise businesses and the newer methodologies are extremely difficult to use in this sort of situation. In this case, I need some specs up front, create dev estimates, all to ultimately deliver a rough dollar amount or sometimes a "not to exceed" number for my boss...

Waterfall is only mostly dead. I'm told that the reason why the public sector prefers price-and-scope-up-front is that the alternative of "we'll keep delivering things as long as you keep paying us" sounds to them far too much like ways that they have been ripped off badly in the past when buying tanks, bridges, etc.

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.

That is absolutely the reason. On top of that, the only reason they want to use iterations (along with the dreaded inchstone) is so they can use Microsoft Project as a progress bar. If you try to change your iteration deliverables (that were set three years ago) because of actual project issues, you get a ration of shit from the government and their advisors.

Bullshit x 2.

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.

Don't know about the formalization by Royce, but I've witnessed and suffered waterfall in practice - let's call it ad-hoc waterfall if you will - and it was no urban legend.

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.

I'll just leave this here.

https://plus.google.com/+LaurentBossavit/posts/VBJTGru3PeW

Or this.

http://leanpub.com/leprechauns

No one ever read Royce's paper, they just accepted the PMI/PMBOK interpretation of it as sacrosanct.

Which was a gross misinterpretation to this day. We still have naive PMPs running $100 million IT projects in the faux-Waterall style.

yeah... i never heard of waterfall until after experiencing a naive use of scrum and having it referred to as 'the alternative'.

Good for you. Some of us old-timers have lived through pure waterfall, waterfall-inspired, and guilt and shame for not doing waterfall right.

The guilt and shame is so spot on. Living though such projects illustrated so well the "the beatings will continue until morale improves" project management school of thoughts.

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.

I was part of a development organization that, driven by guilt and shame, tried to mature and improve their "ad-hoc" processes by fully embracing by-the-book waterfall.

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.

> The guilt and shame is so spot on

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!

oh, don't get me wrong i've worked in that environment, but its just a natural naive way of doing things - dignifying it with a name seems to be something that happened later

Some companies did use it. But even at the time (before Beck's book), it was known in programming literature to be a dumb idea. XP didn't introduce the idea that Waterfall was nonsense, it was just the catylist for it's removal.

Reply on news.ycombinator.com