Maybe they aren't aware of Waterfall. Pete Campbell on Mad Men had a great quote; "You know what? I have good ideas. In fact, I used to carry around a notebook and a pen, just to keep track. Direct marketing? I thought of that. It turned out it already existed, but I arrived at it independently."
We've invented waterfall
31–40 of 172 posts
Re: We've invented waterfall
#32I sent their Chief Architect a linkedin message to make him aware of this thread. Hopefully we'll hear from him.
Re: We've invented waterfall
#33Earlier quoted context omitted.
This was posted on HN so that we can make fun of it, and I think we're right to do so. You can be as wishy washy as you like about different situations requiring different processes, but have you ever seen somebody successfully isolate software engineering from coding and put them in sequence?
Most of us would probably agree that their method is worse than more modern methods, but spending time making fun of them is like making fun of someone for driving an old car. You could be working on your startup right now .
>Most of us would probably agree that their method is worse than more modern methods
Not everyone drank the agile koolaid.
Re: We've invented waterfall
#34The site looks nice. Whether or not their methods are the best, I've worked for quite a few folks who would find their presentation very appealing. Because they've been burned by companies who wrote code for them that didn't meet their expectations, they're excited about a company that will actually listen to their expectations thoroughly before the process begins.
Re: We've invented waterfall
#35How do you do usability testing without the real software having been written?
I never realized just how insane waterfall is until I saw this diagram. Wow.
Re: We've invented waterfall
#36Its really not quite as bad as it looks at first glance. Step 2: "we design an interactive prototype" allows them to get the feedback that really makes more agile methods work. You don't need to constantly iterate during development if you iterate properly during prototyping. I certainly wouldn't advocate this method but its not a vanilla waterfall method.
If one reads the paper most commonly cited as the source of the waterfall methodology he or she will discover that the author of the paper recommends doing something akin to prototyping before designing the real program. The paper is actually a critique of the process now commonly referred to as waterfall and the author does not recommend using the process as first presented in the critique.
Royce's paper can be found here:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...
Re: We've invented waterfall
#37Earlier quoted context omitted.
Most of us would probably agree that their method is worse than more modern methods, but spending time making fun of them is like making fun of someone for driving an old car. You could be working on your startup right now .
>Most of us would probably agree that their method is worse than more modern methods Not everyone drank the agile koolaid.
> Not everyone drank the agile koolaid.
Pure[1] waterfall is doomed from theoretical point of view. You cannot control a system without a feedback loop, unless you have a 100% accurate knowledge of system's state and future evolution. Waterfall lacks feedback loop => you can't really expect much from it.
[1] - in real life there's always some kind of feedback loop in the process; I'd argue that the primary reason why Agile methodologies seem to work better is that they have a much, much tighter feedback loop than waterfall.
Re: We've invented waterfall
#38We've invented the mobile un-friendly site! We are industry pioneers!
How are we missing the -
Paperback + Consultation for $250 Complete 45 page book (45 pages?) Ships within 2 days 1 hour 1-on-1 consultation Expert implementation advice
They sound like experts to me. 37signals book Rework only has 288 pages $11. Page count doesn't mean everything, but clearly 37sig is stuffed with fluff. All you need is 45 to change to the game up.
I'm a non-profit and small business owner, I'm sold!
Re: We've invented waterfall
#39Its really not quite as bad as it looks at first glance. Step 2: "we design an interactive prototype" allows them to get the feedback that really makes more agile methods work. You don't need to constantly iterate during development if you iterate properly during prototyping. I certainly wouldn't advocate this method but its not a vanilla waterfall method.
Agreed - this isn't as poisonous as the usual waterfall techniques are. And frankly, if you're working on a massive project that has strict requirements (either regulatory or functional) then up-front analysis has a lot going for it.
The original waterfall spec. describes the usage of prototypes. I wrote a small review of it a few weeks ago: http://emtrics.com/2011/10/17/software-development-a-little-...
Re: We've invented waterfall
#40Earlier quoted context omitted.
Most of us would probably agree that their method is worse than more modern methods, but spending time making fun of them is like making fun of someone for driving an old car. You could be working on your startup right now .
>Most of us would probably agree that their method is worse than more modern methods Not everyone drank the agile koolaid.
You have a choice of koolaid. The waterfall brand is implicit in the statement "We don't write a line of code until we know your business as well as the people who keep it running every day." - it is founded on the assumption that you can finish requirements for the entire system before starting to deliver working software, and no feedback or iteration is needed.
My experience is that for the majority of software projects, this assumption is horribly broken. And even in fairly well known problem domains where it might work, for the majority of business users wanting new software, the ability to communicate every detail of what it is that they want is horribly lacking.
Scope creep, architecture problems, unanticipated requirements etc. can and does break waterfall projects; this was well known 10 years ago. The probably of it going wrong rises with the size of the project, and it's a curve that's well above linear.
There are two ways out: You can plan for change or you can make the penalties against change more severe - roughly, do even even more big upfront design and penalise change requests; or do less of upfront design, iterate and embrace change. In many cases the "big upfront design" way is impractical in time and expense.
Edit: I found the old article on this subject: "Theory P and Theory D of software construction: Which theory fits the evidence?" http://weblog.raganwald.com/2007/06/which-theory-first-evide...