17 ms·

We've invented waterfall

285 points by latch 15y ago

mrspandex 15y ago
Is this a joke?
- karmajunkie 15y ago
  I honestly thought it was, but crawling the rest of the site it doesn't have an ounce of parody about it. I think these guys really think this is a new methodology...
  - karmajunkie 15y ago
    For example, link to their "Chief Software Architect" linkedin profile: http://www.linkedin.com/profile/view?id=1613224 http://www.linkedin.com/profile/view?id=1613224
    - zht 15y ago
      private
    - deleted 15y ago
      [deleted]
    - mrcharles 15y ago
      Dude has a six year gap in his resume where he goes from being a web designer to chief architect? That might explain why he thinks waterfall is new.
      - donw 15y ago
        All of his (their?) work appears to be small-scale websites for small companies -- it doesn't look like he's built anything really substantial.
      - bigohms 15y ago
        Can we see a link to your LinkedIn profile?
        mrcharles 15y ago
        Too lazy to figure out how to get a shareable link from LinkedIn, but feel free to look up Charles Randall who is currently at Ubisoft Toronto. Not that I know what this proves, other than Linked In's shitty use of URLs.
bruinseve 15y ago
Sadly, I don't think this is a joke. Method as described: "Analysis We don't write a line of code until we know your business as well as the people who keep it running every day. " Method as implemented: "Analysis We never write any code"
davidu 15y ago
This doesn't look like a joke. Dangerous. Anyone who has done this methodology runs screaming for an exit after a failed project or two.
- tintin 15y ago
  Not so fast. This isn't something new or strange at all. We are doing this for years with great success. But maybe you know this method as these steps (which are the same): Concept -> Functional design -> Graphic design -> Building -> Testing -> Deploy. Nothing strange about that. Take a look at the IBM Rational Unified Process http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process I just think this is a hyped site trying to sell there book.
  - outworlder 15y ago
    Or better yet: don't ever look at anything from Rational (now IBM). Unless you are a consulting company the size of IBM. With the same business model.
  - aidenn0 15y ago
    It's not new or strange at all, but I would hesitate to call it a success.
brd 15y ago
Its 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.
- AndrewDucker 15y ago
  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.
  - edu 15y ago
    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-bit-of-history/ http://emtrics.com/2011/10/17/software-development-a-little-...
- ctdonath 15y ago
  That they insert what amounts to a single early design iteration hardly rescues the inanity of "hey! I sliced bread! this is awesome!"
- absconditus 15y ago
  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.
  - arctangent 15y ago
    Royce's paper can be found here: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...
tpatke 15y ago
Meh. This is hardly the most ridiculous thing I have seen on the internet. I am sure this methodology will work sometimes for some clients. Heck, I bet a lot of startups here on HackerNews are using similar methodologies - but without the early usability testing. If nothing else, at least this company are differentiating themselves. Haven't seen a lot of other consultancies get posted up here on HackerNews. Every project is different. We should try and not be too dogmatic about these things.
- goldmab 15y ago
  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?
  - pingswept 15y ago
    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.
    - SomeOtherGuy 15y ago
      >Most of us would probably agree that their method is worse than more modern methods Not everyone drank the agile koolaid.
      - TeMPOraL 15y ago
        > 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.
stfu 15y ago
The sad part is, that most of their clients are probably buying into this and think what an excellent and innovative company they hired.
ctdonath 15y ago
Few seem to realize that source code is but the most thorough "blueprint" of the product. That compilation - to wit construction of the actual product from the blueprint - is nigh unto instant and free means everyone overlooks it as the actual construction process, akin to actually building a bridge from detailed plans (except you get one shot at building a bridge, while you can recompile every few minutes). Ergo, "analysis", at greatest detail, _is_ coding. That we iterate so much comes from the continued newness of the technology and the relative complexity of the products; bridges are well-understood and iterating the design of one is minimal. To the site's point (or missing thereof), the notion of "don't start coding until the analysis is complete" is a gross misunderstanding that coding IS analysis. The inanity of reinventing the waterfall model is obvious to HN readers.
- goldmab 15y ago
  It sounds like you're saying something similar to this: http://www.developerdotstar.com/mag/articles/reeves_design.html http://www.developerdotstar.com/mag/articles/reeves_design.h...
manuscreationis 15y ago
Doesn't look as terrible as "true" waterfall, but I think this is just marketing fluff to win people over by telling them about your rock-solid practices. If they have an arrow that looped from Beta Testing back into Interface Design/Usability/Engineering/Coding, you'd probably end up with what most shops do anyways, speaking in broad strokes.
cridal 15y ago
"We've invented cigarettes", come buy a pack... everything that doesn't kill you makes you stronger...
bernardes 15y ago
"Unlike a traditional development process, ours establishes all the system's requirements before a line of code is written." This is freakin' unbelievable. ROFL
- blueprint 15y ago
  Might explain why the "Code" part of their process seems so lacking in substantial details!
fijal 15y ago
Did you notice how men in suits are left and right but not in the middle?
- tryke 15y ago
  I wondered who the man with the clipboard was, micro-managing every step of the process.
- wingo 15y ago
  My favorite was the mud-robot dominated by a timepiece.
- reledi 15y ago
  My favourite part was how the people appear to hate their jobs. Only in the last panel (Deployment) do you see anyone from the team smiling.
Ronnie76er 15y ago
Waterfall isn't bad in all circumstances. Lockheed Martin isn't iterating a jet into the side of a mountain 100 times until they get it right.
- dylancm 15y ago
  have you _seen_ the US's defense budget?
- TeMPOraL 15y ago
  tl; dr: I think Waterfall vs. Agile religious war is wrong; it's mostly about that you can't hit a moving target without a feedback loop. That's why I don't think the discussion should really be Waterfall vs. Agile, it should be about feedback loops in the process. There are circumstances in e.g. military or medical projects where you absolutely, positively, need to work to an approved spec with time & budget analysis, etc.; it seems to be common outside of software (I don't see much of agile-built bridges or jetplanes). There are those parts of the process that can be predicted (and have their cost estimated) relatively well - those you plan in advance (aka. waterfall). There are others, where you only have a somewhat vague and changing final goal - there your only real solution is a process with a tight feedback loop (aka. agile). Now you can look at software process on different levels - what might look like waterfall from the high level may be in fact a collection of very agile sub-processes. Which may contain waterfally sub-levels (like, isn't a single iteration of TDD red-green-refactor cycle a bit waterfally? ;). So I think instead of thinking about "agile vs. waterfall" we should consider what feedback loops we need where, and how tight they should be.
  - aidenn0 15y ago
    The definition of waterfall is that there is no loop. When one step is done, it's done.
- arctangent 15y ago
  Perhaps not. But they're probably running a computer model of the jet (and its systems) under various simulated scenarios. They're also probably building some full-scale mock-ups to test in wind tunnels. And they also have test pilots to fly things which sometimes never make it into wide scale production. So, I'd argue that there is some iteration going on there.
shareme 15y ago
Would this help design a process to Balance the US gov budget?
tpimental 15y ago
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."
- joshsusser 15y ago
  If they are such experts, how would they not be aware of waterfall? Either they are idiots who have no clue about software development methodology, or they are just lying (either to their customers or themselves). It's not like it's hard to find a reference to waterfall if you bother to look.
shotgun 15y ago
I sent their Chief Architect a linkedin message to make him aware of this thread. Hopefully we'll hear from him.
bmccormack 15y ago
The 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.
jrockway 15y ago
How 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.
fypomg 15y ago
We'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!
giberson 15y ago
Here's what I would like to see from a consulting company for once. Don't interview the stake holders of the company, they don't use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you're getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn't require mentioning. So here's what you should do. Over the shoulder review of a representative employee of each department. HR, AP, AR etc. Actively watch and understand the processes they go through. FOR AN ENTIRE 8 HOUR SHIFT. No, seriously. Now, you've got a good idea of how its done current. Then do the stake holder interview to find out what they want to do differently. Then plan, develop and deploy your software. I seriously don't get why despite there being a recognized need for understanding the problem scope which everyone one will invest hours in meetings and conference calls talking about, no one actually invests any (significant) time doing, or reviewing the actual process. It's the fastest most efficient way to understand the problem. It would totally diminish months of back and forth "here's what you asked for" "no, that's not what I asked for" development review process that almost _always_ occurs with consultant projects. /rant
- TheCapn 15y ago
  Say what you will about large corporations but at the very least they can get this right. I'm working for a 4,000+ company now and we take these steps very seriously during our Engineering design. Also part of the job is working with vendors (Oracle, HP, others) who send people on sight from around the world to work with us (the client) and properly interview for the right knowledge. Call me bias, but a lot of smaller companies overlook tried and tested standards. Proper requirement elicitation was documented in IEEE Computer Society SWEBOK prior to 2004 and even that is a summary of important knowledge to Software Engineering profession. Why is it that when a new company comes along with a truly innovative concept they feel they can innovate the rest of the process as well?
- roc 15y ago
  Let me tell you why you don't see this happening more often. I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department. Everyone who directly interacted with the new system loved it. Numerous edge cases that would have been lost in high-level review were caught and integrated from day 1 due to my actually watching people do the job for a day or two per department. The solution has been rock solid (minor maintenance only) for five years. And I almost lost the job. The people who sign the checks were furious. The balance of political power between departments were thrown for a loop. One head in particular treated the thing as a near-existential threat. His entire concept of his job revolved around being the authoritative interface for retrieving and maintaining pieces of data that were no longer exclusively under his control. Another flipped out because middle management saw the results as cause to reduce his headcount and budget, and thus importance. These two departments fought for months, refusing to contribute their shares of budget that were pledged toward modernizing this system. On a technical and practical level, it was the single best experience I've ever had as a consultant. On a personal and economic level, is was one of the worst. It was some of the hardest money I've ever tried to collect. It was some of the most time and energy I've put into the political and 'sales' side of a job (the part I treat as a necessary evil, but very much evil). The corporation has made out like a bandit in the long run. But I paid the price. It's simply too easy and financially rewarding to allow a client's political nonsense to screw up every stage of a project. I have less stress, the people who pay me are happier and I bill far more hours. As with most software, internally developed software included, you don't see better projects more often because the incentives are horribly perverted and stacked against it.
ap22213 15y ago
Hilarious. But all jokes aside, have you ever tried to explain to a self-described 'technical-enough-to-be-dangerous' corporate middle manager what an iterative and incremental process is?
willurd 15y ago
I actually know Clark Valberg, the founder of Epicenter Consulting, and did some work with him a few years back; he's a great guy. You guys can criticize him all you want, but he actually cares. We should direct our efforts towards the bloodsuckers, not the people giving blood.
- rickmb 15y ago
  We you say "he cares" I presume you mean "cares about slick marketing to clueless clients". Because Epicenter obviously doesn't give a damn about either the truth or software engineering. I'm sorry, but the people who claim the one true method is keeping the programmers locked in the basement without real world input or feedback are the bloodsuckers.
  - willurd 15y ago
    No, I mean that he cares about giving his clients a great product. He's not just in it to soak money out of people; he actually cares about the outcome, much like an artist cares about their paintings. And look, I'm not Clark. I don't speak for Clark. This is just the experience I had working with him and getting to know him for a year and a half.
    - raymondcamden 15y ago
      I can ditto this. I've known Clark for years. He is an honorable person, as is his coworker Ben Nadel. Fault them if you will for 'inventing' something that already existed, but this was - at worst - an innocent mistake. How many people here have reached out to them to try to help correct their mistake?
zedshaw 15y ago
Actually, this is refreshingly honest compared to the "agile" methodologies. Having worked with plenty of supposedly agile consultants I can tell you they basically do waterfall it's just their cascading stupidity starts with code and then wanders around writing unit tests until the client is tapped out. At least this is doing some actual user interface design and usability testing. Then again, I doubt these guys do this since it's all marketing.
- jameskilton 15y ago
  Really? Claiming to have invented the most well know and also the worst software development process is honest? It's a bold-faced lie written only to get clients. One can only imagine what actually happens in communication once they have a client. If the marketing is a complete lie, then I can't imagine the company itself can be trusted.
  - zedshaw 15y ago
    >Claiming to have invented the most well know and also the worst software development process is honest? They claim to have developed the best process, just like all the agile con artists out there.
- bh42222 15y ago
  The difference between "agile" and "waterfall" isn't that easy to pin down. Some people think of "agile" as just going through their full waterfall process every month or every two weeks. Other people insist the core of "agile" is TDD, others claim nonsense, TDD is just as much part of "waterfall", and yet others don't see any point in TDD for their "agile" process. tl;dr: It's all bullshit, all the way down.
- sleight42 15y ago
  Most "agile" consultants you know start coding from day one? If so, I now understand much better why you dump so much on agile. I had myself a nice little nerd slap fight on twitter earlier today about this post. "Agile" without up front planning and research is just dangerous.
MattRogish 15y ago
If you read the book's PDF (http://epicenterconsulting.com/book_source/Obsessively-Thorough-Software-Design-Preview.pdf http://epicenterconsulting.com/book_source/Obsessively-Thoro...) you'll also note that: "Hal was the first to introduce the concept of building an interactive demo as a key part of the software development process" Really? I can't imagine that's true
- winterwaterfall 15y ago
  Check out Hal's website with JavaScript disabled: http://www.halhelms.com/ http://www.halhelms.com/ What's going on there? Hal Helms home helplessly hacked? Or just poor page design?
dicroce 15y ago
Ok, I just invented a new methodology, I dub thee: "Agilefall" First we meet and discuss the goals for the sprint. Then I design (usually some class diagrams on a sheet of paper or board), then I code and test it (unit tests of course) and finally check it in. Each 4 to 6 week sprint is internally structured as a waterfall. :)
bascule 15y ago
I thought the most bothersome thing on the entire page was the claim they put "business over code". Without working software you don't have a business.
j45 15y ago
Am I in the minority who uses both agile and waterfall methods? The long and the short of it for me is this: There's two ways to solve problems. Agile helps immensely when you are figuring out how the solution would work. When you're solving a problem that might be solved in manual processes largely, Waterfall can help a lot, but not alone. For unknown solutions, agile gives you a lot of iterative benefits. For known solutions, waterfall with some agile feedback loops gives you incremental benefits. What's the difference? Sometimes, in a business, they have a great process already. It's in paper, or multiple systems, but they have their way of doing things that works. I believe it's called their competitive advantage. Othertimes, a business is facing a problem for the first time, and wonder "how do we solve this". In this case, doing a big upfront design is a waste of time, starting small and staying flexible is most important. For me, this mindset of doing both is critical, not one or the other at all times. You simply miss out on too much if you don't use agile, and you run around too much if you ignore waterfall when a solution exists. Waterfall works where it's a known process, like building a house. You can have agile loops in there when building a house and improve it as you go. When you're trying to build a new building that's never been built before, an iterative, feedback-centric approach like Agile is a lot more beneficial. If a company focuses on taking something like Waterfall and introducing feedback loops (agile) like this epicenter thing, is it not a bit clearer than the black-box voodoo out there? Maybe it's just me, but I applaud anyone trying to make software easier. It just shouldn't be a dogmatic, or religious dismissal. 0.02.
feedus 15y ago
I've invented "rock". I don't talk to anyone. I look at the crap you're using and make something new. I give you the URL. Figure it out on your own. Invoice due on receipt.
msluyter 15y ago
I love the fact that the software engineers basically deliver UML diagrams to the coders. I'd shoot myself if that were all there was to my job.
Amadeus2011 15y ago
Some of these comments are missing the point. Their methodology isn't about how to build but on what to build. It's a problem many industries face. When the client is a non-technical person (the norm in making web apps) building the UI first makes good sense.
- johnx123-up 15y ago
  I agree. Most of the comments are overlooked. I suspect that the OP is competitor to the said company?
eweise 15y ago
I love how each coder has a giant clock right in front of their face.
alabut 15y ago
I've got a bone to pick with people that have a bone to pick with waterfall, especially when they don't realize that whatever competing newer workflow they swear by is actually waterfall in disguise. Let's just ignore for a second that a waterfall process sent men to the moon and continues to build skyscrapers, with each project having a set of stakeholders the size of a small city and all while adjusting to a shifting landscape of nearly infinite variables. Especially the first few moon missions, when no one had done it before. It's why all of the original astronauts were test pilots - not just because of their bravado but also their experience in co-designing unfinished machines along with the engineers to bring it to a workable finished state. The roots of the modern HCI and human factors industries comes from analyzing and optimizing the usability of cockpits. The astronauts even had their own usability jokes about a model of training jet that was so user-unfriendly that the emergency instructions for ejection were printed on the side of the canopy, which is nuts because step one was to blow the canopy (along with the rest of the instructions) up off into the sky. These weren't dumb monkeys strapped to a giant tin can and blown into space, and neither were the engineers that sent them there. With waterfall. So you use agile/xp/scrum/whatever and swear software is way different than building bridges. I've worked on and with several of those teams, with varying levels of strictness, and guess what? It's still basically waterfall. But instead of PMs owning the process and spec'ing things out in advance, engineers own the process and the spec is written and re-written during development on a bunch of index cards with sharpies like a grade school art project (or the digital equivalent), designers get barely a week ahead of each sprint or run around like caffeinated janitors cleaning up after each sprint, and documentation gets written last or not at all. And before anyone does ad hominem attacks on whether my teams were doing agile correctly, this is the same dynamic I witnessed at the most famous agile and rails development shop you can think of. You probably only need one guess to figure out who it is. What matters then, if it's not process? It's called expertise - a broad collection of various techniques and the context-specific awareness of when to use each one. Instead of blindly following a process and trying to hammer it into every situation, take a tools-instead-of-rules approach to using whatever techniques are appropriate for each project. For anyone interested in this kind of flexible thinking instead of linear GTD productivity tools that leave you stuck in robot mode, there's an excellent book called Pragmatic Thinking And Learning that goes into a lot more detail and pulls inspiration from how the nursing industry overhauled their education system in the 70's. http://pragprog.com/book/ahptl/pragmatic-thinking-and-learning http://pragprog.com/book/ahptl/pragmatic-thinking-and-learni... I know, from the book publisher that sells the pickaxe Rails book and stuff on agile. Oh the irony!
peteforde 15y ago
My founding business partner Ryan McMinn spoke at an open source conference in Toronto a few years ago. In the talk he explained how and why we built Unspace the way that we did. http://www.youtube.com/watch?v=lIQIZ0NIkxk http://www.youtube.com/watch?v=lIQIZ0NIkxk He talks extensively about the need to work directly with the end users of the system, instead of the management. The realization that specifications are usually nothing more than mutually assured destruction. Pretty much the only thing that's changed in five years is that the scale of our company has grown, and now we do indeed have contracts with our clients to protect us from bad things. Anyhow, I highly recommend the video if you're looking for an in-the-trenches perspective.
nickfrost 15y ago
Thank you @JoshSusser for finding this diamond in the rough. What would we do without waterfall development!?
jhrobert 15y ago
The problem with both waterfall and agile is that we are missing the definition of "the Humble process" to develop software. Unfortunately humility does not sell so well.
buff-a 15y ago
In an ideal world, Waterfall will lead to a worse product than an iterative one. We don't live in the real world, and I expect these guys deal with clients who regularly fall into the -from-hell[1] category. I would bet that many people posting here aren't running consultancies and don't have experience with such clients (or any clients). In such a situation, it is in fact entirely rational to develop a lightweight, low cost UI that a non-technical person can commit to, i.e. sign a contract. The developer can then go off and implement it with a very clear legal case if the client then chooses not to pay because "its not what we wanted". Its not what I do, and I know that many here take a more involved approach to their clients, but its undeniable that it is a successful business model, and in some cases I believe it can produce some result where otherwise there might be none. Equally I'm sure it produces results that are ultimately not used, but where the company still gets paid. [1] http://clientsfromhell.net/ http://clientsfromhell.net/
Morendil 15y ago
What I love best is this testimonial praising the book: > Helms and Valberg lay out an innovative methodology that finally delivers on the promise of Agile Development.
reledi 15y ago
Epicenter is sending out some annoyed tweets while defending the AgileUX movement. They claim their process is nothing like waterfall as it focuses on iterative UX prototyping. https://twitter.com/epicenternyc https://twitter.com/epicenternyc

285 points by latch 15y ago

mrspandex 15y ago

Is this a joke?

karmajunkie 15y ago
I honestly thought it was, but crawling the rest of the site it doesn't have an ounce of parody about it. I think these guys really think this is a new methodology...
- karmajunkie 15y ago
  For example, link to their "Chief Software Architect" linkedin profile: http://www.linkedin.com/profile/view?id=1613224 http://www.linkedin.com/profile/view?id=1613224
  - zht 15y ago
    private
  - deleted 15y ago
    [deleted]
  - mrcharles 15y ago
    Dude has a six year gap in his resume where he goes from being a web designer to chief architect? That might explain why he thinks waterfall is new.
    - donw 15y ago
      All of his (their?) work appears to be small-scale websites for small companies -- it doesn't look like he's built anything really substantial.
    - bigohms 15y ago
      Can we see a link to your LinkedIn profile?
      - mrcharles 15y ago
        Too lazy to figure out how to get a shareable link from LinkedIn, but feel free to look up Charles Randall who is currently at Ubisoft Toronto. Not that I know what this proves, other than Linked In's shitty use of URLs.

bruinseve 15y ago

Sadly, I don't think this is a joke. Method as described: "Analysis We don't write a line of code until we know your business as well as the people who keep it running every day. " Method as implemented: "Analysis We never write any code"

davidu 15y ago

This doesn't look like a joke. Dangerous. Anyone who has done this methodology runs screaming for an exit after a failed project or two.

tintin 15y ago
Not so fast. This isn't something new or strange at all. We are doing this for years with great success. But maybe you know this method as these steps (which are the same): Concept -> Functional design -> Graphic design -> Building -> Testing -> Deploy. Nothing strange about that. Take a look at the IBM Rational Unified Process http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process I just think this is a hyped site trying to sell there book.
- outworlder 15y ago
  Or better yet: don't ever look at anything from Rational (now IBM). Unless you are a consulting company the size of IBM. With the same business model.
- aidenn0 15y ago
  It's not new or strange at all, but I would hesitate to call it a success.

brd 15y ago

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

AndrewDucker 15y ago
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.
- edu 15y ago
  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-bit-of-history/ http://emtrics.com/2011/10/17/software-development-a-little-...
ctdonath 15y ago
That they insert what amounts to a single early design iteration hardly rescues the inanity of "hey! I sliced bread! this is awesome!"
absconditus 15y ago
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.
- arctangent 15y ago
  Royce's paper can be found here: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...

tpatke 15y ago

Meh. This is hardly the most ridiculous thing I have seen on the internet. I am sure this methodology will work sometimes for some clients. Heck, I bet a lot of startups here on HackerNews are using similar methodologies - but without the early usability testing. If nothing else, at least this company are differentiating themselves. Haven't seen a lot of other consultancies get posted up here on HackerNews. Every project is different. We should try and not be too dogmatic about these things.

goldmab 15y ago
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?
- pingswept 15y ago
  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.
  - SomeOtherGuy 15y ago
    >Most of us would probably agree that their method is worse than more modern methods Not everyone drank the agile koolaid.
    - TeMPOraL 15y ago
      > 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.

stfu 15y ago

The sad part is, that most of their clients are probably buying into this and think what an excellent and innovative company they hired.

ctdonath 15y ago

Few seem to realize that source code is but the most thorough "blueprint" of the product. That compilation - to wit construction of the actual product from the blueprint - is nigh unto instant and free means everyone overlooks it as the actual construction process, akin to actually building a bridge from detailed plans (except you get one shot at building a bridge, while you can recompile every few minutes). Ergo, "analysis", at greatest detail, _is_ coding. That we iterate so much comes from the continued newness of the technology and the relative complexity of the products; bridges are well-understood and iterating the design of one is minimal. To the site's point (or missing thereof), the notion of "don't start coding until the analysis is complete" is a gross misunderstanding that coding IS analysis. The inanity of reinventing the waterfall model is obvious to HN readers.

goldmab 15y ago
It sounds like you're saying something similar to this: http://www.developerdotstar.com/mag/articles/reeves_design.html http://www.developerdotstar.com/mag/articles/reeves_design.h...

manuscreationis 15y ago

Doesn't look as terrible as "true" waterfall, but I think this is just marketing fluff to win people over by telling them about your rock-solid practices. If they have an arrow that looped from Beta Testing back into Interface Design/Usability/Engineering/Coding, you'd probably end up with what most shops do anyways, speaking in broad strokes.

cridal 15y ago

"We've invented cigarettes", come buy a pack... everything that doesn't kill you makes you stronger...

bernardes 15y ago

"Unlike a traditional development process, ours establishes all the system's requirements before a line of code is written." This is freakin' unbelievable. ROFL

blueprint 15y ago
Might explain why the "Code" part of their process seems so lacking in substantial details!

fijal 15y ago

Did you notice how men in suits are left and right but not in the middle?

tryke 15y ago
I wondered who the man with the clipboard was, micro-managing every step of the process.
wingo 15y ago
My favorite was the mud-robot dominated by a timepiece.
reledi 15y ago
My favourite part was how the people appear to hate their jobs. Only in the last panel (Deployment) do you see anyone from the team smiling.

Ronnie76er 15y ago

Waterfall isn't bad in all circumstances. Lockheed Martin isn't iterating a jet into the side of a mountain 100 times until they get it right.

dylancm 15y ago
have you _seen_ the US's defense budget?
TeMPOraL 15y ago
tl; dr: I think Waterfall vs. Agile religious war is wrong; it's mostly about that you can't hit a moving target without a feedback loop. That's why I don't think the discussion should really be Waterfall vs. Agile, it should be about feedback loops in the process. There are circumstances in e.g. military or medical projects where you absolutely, positively, need to work to an approved spec with time & budget analysis, etc.; it seems to be common outside of software (I don't see much of agile-built bridges or jetplanes). There are those parts of the process that can be predicted (and have their cost estimated) relatively well - those you plan in advance (aka. waterfall). There are others, where you only have a somewhat vague and changing final goal - there your only real solution is a process with a tight feedback loop (aka. agile). Now you can look at software process on different levels - what might look like waterfall from the high level may be in fact a collection of very agile sub-processes. Which may contain waterfally sub-levels (like, isn't a single iteration of TDD red-green-refactor cycle a bit waterfally? ;). So I think instead of thinking about "agile vs. waterfall" we should consider what feedback loops we need where, and how tight they should be.
- aidenn0 15y ago
  The definition of waterfall is that there is no loop. When one step is done, it's done.
arctangent 15y ago
Perhaps not. But they're probably running a computer model of the jet (and its systems) under various simulated scenarios. They're also probably building some full-scale mock-ups to test in wind tunnels. And they also have test pilots to fly things which sometimes never make it into wide scale production. So, I'd argue that there is some iteration going on there.

shareme 15y ago

Would this help design a process to Balance the US gov budget?

tpimental 15y ago

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

joshsusser 15y ago
If they are such experts, how would they not be aware of waterfall? Either they are idiots who have no clue about software development methodology, or they are just lying (either to their customers or themselves). It's not like it's hard to find a reference to waterfall if you bother to look.

shotgun 15y ago

I sent their Chief Architect a linkedin message to make him aware of this thread. Hopefully we'll hear from him.

bmccormack 15y ago

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

jrockway 15y ago

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

fypomg 15y ago

We'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!

giberson 15y ago

Here's what I would like to see from a consulting company for once. Don't interview the stake holders of the company, they don't use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you're getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn't require mentioning. So here's what you should do. Over the shoulder review of a representative employee of each department. HR, AP, AR etc. Actively watch and understand the processes they go through. FOR AN ENTIRE 8 HOUR SHIFT. No, seriously. Now, you've got a good idea of how its done current. Then do the stake holder interview to find out what they want to do differently. Then plan, develop and deploy your software. I seriously don't get why despite there being a recognized need for understanding the problem scope which everyone one will invest hours in meetings and conference calls talking about, no one actually invests any (significant) time doing, or reviewing the actual process. It's the fastest most efficient way to understand the problem. It would totally diminish months of back and forth "here's what you asked for" "no, that's not what I asked for" development review process that almost _always_ occurs with consultant projects. /rant

TheCapn 15y ago
Say what you will about large corporations but at the very least they can get this right. I'm working for a 4,000+ company now and we take these steps very seriously during our Engineering design. Also part of the job is working with vendors (Oracle, HP, others) who send people on sight from around the world to work with us (the client) and properly interview for the right knowledge. Call me bias, but a lot of smaller companies overlook tried and tested standards. Proper requirement elicitation was documented in IEEE Computer Society SWEBOK prior to 2004 and even that is a summary of important knowledge to Software Engineering profession. Why is it that when a new company comes along with a truly innovative concept they feel they can innovate the rest of the process as well?
roc 15y ago
Let me tell you why you don't see this happening more often. I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department. Everyone who directly interacted with the new system loved it. Numerous edge cases that would have been lost in high-level review were caught and integrated from day 1 due to my actually watching people do the job for a day or two per department. The solution has been rock solid (minor maintenance only) for five years. And I almost lost the job. The people who sign the checks were furious. The balance of political power between departments were thrown for a loop. One head in particular treated the thing as a near-existential threat. His entire concept of his job revolved around being the authoritative interface for retrieving and maintaining pieces of data that were no longer exclusively under his control. Another flipped out because middle management saw the results as cause to reduce his headcount and budget, and thus importance. These two departments fought for months, refusing to contribute their shares of budget that were pledged toward modernizing this system. On a technical and practical level, it was the single best experience I've ever had as a consultant. On a personal and economic level, is was one of the worst. It was some of the hardest money I've ever tried to collect. It was some of the most time and energy I've put into the political and 'sales' side of a job (the part I treat as a necessary evil, but very much evil). The corporation has made out like a bandit in the long run. But I paid the price. It's simply too easy and financially rewarding to allow a client's political nonsense to screw up every stage of a project. I have less stress, the people who pay me are happier and I bill far more hours. As with most software, internally developed software included, you don't see better projects more often because the incentives are horribly perverted and stacked against it.

ap22213 15y ago

Hilarious. But all jokes aside, have you ever tried to explain to a self-described 'technical-enough-to-be-dangerous' corporate middle manager what an iterative and incremental process is?

willurd 15y ago

I actually know Clark Valberg, the founder of Epicenter Consulting, and did some work with him a few years back; he's a great guy. You guys can criticize him all you want, but he actually cares. We should direct our efforts towards the bloodsuckers, not the people giving blood.

rickmb 15y ago
We you say "he cares" I presume you mean "cares about slick marketing to clueless clients". Because Epicenter obviously doesn't give a damn about either the truth or software engineering. I'm sorry, but the people who claim the one true method is keeping the programmers locked in the basement without real world input or feedback are the bloodsuckers.
- willurd 15y ago
  No, I mean that he cares about giving his clients a great product. He's not just in it to soak money out of people; he actually cares about the outcome, much like an artist cares about their paintings. And look, I'm not Clark. I don't speak for Clark. This is just the experience I had working with him and getting to know him for a year and a half.
  - raymondcamden 15y ago
    I can ditto this. I've known Clark for years. He is an honorable person, as is his coworker Ben Nadel. Fault them if you will for 'inventing' something that already existed, but this was - at worst - an innocent mistake. How many people here have reached out to them to try to help correct their mistake?

zedshaw 15y ago

Actually, this is refreshingly honest compared to the "agile" methodologies. Having worked with plenty of supposedly agile consultants I can tell you they basically do waterfall it's just their cascading stupidity starts with code and then wanders around writing unit tests until the client is tapped out. At least this is doing some actual user interface design and usability testing. Then again, I doubt these guys do this since it's all marketing.

jameskilton 15y ago
Really? Claiming to have invented the most well know and also the worst software development process is honest? It's a bold-faced lie written only to get clients. One can only imagine what actually happens in communication once they have a client. If the marketing is a complete lie, then I can't imagine the company itself can be trusted.
- zedshaw 15y ago
  >Claiming to have invented the most well know and also the worst software development process is honest? They claim to have developed the best process, just like all the agile con artists out there.
bh42222 15y ago
The difference between "agile" and "waterfall" isn't that easy to pin down. Some people think of "agile" as just going through their full waterfall process every month or every two weeks. Other people insist the core of "agile" is TDD, others claim nonsense, TDD is just as much part of "waterfall", and yet others don't see any point in TDD for their "agile" process. tl;dr: It's all bullshit, all the way down.
sleight42 15y ago
Most "agile" consultants you know start coding from day one? If so, I now understand much better why you dump so much on agile. I had myself a nice little nerd slap fight on twitter earlier today about this post. "Agile" without up front planning and research is just dangerous.

MattRogish 15y ago

If you read the book's PDF (http://epicenterconsulting.com/book_source/Obsessively-Thorough-Software-Design-Preview.pdf http://epicenterconsulting.com/book_source/Obsessively-Thoro...) you'll also note that: "Hal was the first to introduce the concept of building an interactive demo as a key part of the software development process" Really? I can't imagine that's true

winterwaterfall 15y ago
Check out Hal's website with JavaScript disabled: http://www.halhelms.com/ http://www.halhelms.com/ What's going on there? Hal Helms home helplessly hacked? Or just poor page design?

dicroce 15y ago

Ok, I just invented a new methodology, I dub thee: "Agilefall" First we meet and discuss the goals for the sprint. Then I design (usually some class diagrams on a sheet of paper or board), then I code and test it (unit tests of course) and finally check it in. Each 4 to 6 week sprint is internally structured as a waterfall. :)

bascule 15y ago

I thought the most bothersome thing on the entire page was the claim they put "business over code". Without working software you don't have a business.

j45 15y ago

Am I in the minority who uses both agile and waterfall methods? The long and the short of it for me is this: There's two ways to solve problems. Agile helps immensely when you are figuring out how the solution would work. When you're solving a problem that might be solved in manual processes largely, Waterfall can help a lot, but not alone. For unknown solutions, agile gives you a lot of iterative benefits. For known solutions, waterfall with some agile feedback loops gives you incremental benefits. What's the difference? Sometimes, in a business, they have a great process already. It's in paper, or multiple systems, but they have their way of doing things that works. I believe it's called their competitive advantage. Othertimes, a business is facing a problem for the first time, and wonder "how do we solve this". In this case, doing a big upfront design is a waste of time, starting small and staying flexible is most important. For me, this mindset of doing both is critical, not one or the other at all times. You simply miss out on too much if you don't use agile, and you run around too much if you ignore waterfall when a solution exists. Waterfall works where it's a known process, like building a house. You can have agile loops in there when building a house and improve it as you go. When you're trying to build a new building that's never been built before, an iterative, feedback-centric approach like Agile is a lot more beneficial. If a company focuses on taking something like Waterfall and introducing feedback loops (agile) like this epicenter thing, is it not a bit clearer than the black-box voodoo out there? Maybe it's just me, but I applaud anyone trying to make software easier. It just shouldn't be a dogmatic, or religious dismissal. 0.02.

feedus 15y ago

I've invented "rock". I don't talk to anyone. I look at the crap you're using and make something new. I give you the URL. Figure it out on your own. Invoice due on receipt.

msluyter 15y ago

I love the fact that the software engineers basically deliver UML diagrams to the coders. I'd shoot myself if that were all there was to my job.

Amadeus2011 15y ago

Some of these comments are missing the point. Their methodology isn't about how to build but on what to build. It's a problem many industries face. When the client is a non-technical person (the norm in making web apps) building the UI first makes good sense.

johnx123-up 15y ago
I agree. Most of the comments are overlooked. I suspect that the OP is competitor to the said company?

eweise 15y ago

I love how each coder has a giant clock right in front of their face.

alabut 15y ago

I've got a bone to pick with people that have a bone to pick with waterfall, especially when they don't realize that whatever competing newer workflow they swear by is actually waterfall in disguise. Let's just ignore for a second that a waterfall process sent men to the moon and continues to build skyscrapers, with each project having a set of stakeholders the size of a small city and all while adjusting to a shifting landscape of nearly infinite variables. Especially the first few moon missions, when no one had done it before. It's why all of the original astronauts were test pilots - not just because of their bravado but also their experience in co-designing unfinished machines along with the engineers to bring it to a workable finished state. The roots of the modern HCI and human factors industries comes from analyzing and optimizing the usability of cockpits. The astronauts even had their own usability jokes about a model of training jet that was so user-unfriendly that the emergency instructions for ejection were printed on the side of the canopy, which is nuts because step one was to blow the canopy (along with the rest of the instructions) up off into the sky. These weren't dumb monkeys strapped to a giant tin can and blown into space, and neither were the engineers that sent them there. With waterfall. So you use agile/xp/scrum/whatever and swear software is way different than building bridges. I've worked on and with several of those teams, with varying levels of strictness, and guess what? It's still basically waterfall. But instead of PMs owning the process and spec'ing things out in advance, engineers own the process and the spec is written and re-written during development on a bunch of index cards with sharpies like a grade school art project (or the digital equivalent), designers get barely a week ahead of each sprint or run around like caffeinated janitors cleaning up after each sprint, and documentation gets written last or not at all. And before anyone does ad hominem attacks on whether my teams were doing agile correctly, this is the same dynamic I witnessed at the most famous agile and rails development shop you can think of. You probably only need one guess to figure out who it is. What matters then, if it's not process? It's called expertise - a broad collection of various techniques and the context-specific awareness of when to use each one. Instead of blindly following a process and trying to hammer it into every situation, take a tools-instead-of-rules approach to using whatever techniques are appropriate for each project. For anyone interested in this kind of flexible thinking instead of linear GTD productivity tools that leave you stuck in robot mode, there's an excellent book called Pragmatic Thinking And Learning that goes into a lot more detail and pulls inspiration from how the nursing industry overhauled their education system in the 70's. http://pragprog.com/book/ahptl/pragmatic-thinking-and-learning http://pragprog.com/book/ahptl/pragmatic-thinking-and-learni... I know, from the book publisher that sells the pickaxe Rails book and stuff on agile. Oh the irony!

peteforde 15y ago

My founding business partner Ryan McMinn spoke at an open source conference in Toronto a few years ago. In the talk he explained how and why we built Unspace the way that we did. http://www.youtube.com/watch?v=lIQIZ0NIkxk http://www.youtube.com/watch?v=lIQIZ0NIkxk He talks extensively about the need to work directly with the end users of the system, instead of the management. The realization that specifications are usually nothing more than mutually assured destruction. Pretty much the only thing that's changed in five years is that the scale of our company has grown, and now we do indeed have contracts with our clients to protect us from bad things. Anyhow, I highly recommend the video if you're looking for an in-the-trenches perspective.

nickfrost 15y ago

Thank you @JoshSusser for finding this diamond in the rough. What would we do without waterfall development!?

jhrobert 15y ago

The problem with both waterfall and agile is that we are missing the definition of "the Humble process" to develop software. Unfortunately humility does not sell so well.

buff-a 15y ago

In an ideal world, Waterfall will lead to a worse product than an iterative one. We don't live in the real world, and I expect these guys deal with clients who regularly fall into the -from-hell[1] category. I would bet that many people posting here aren't running consultancies and don't have experience with such clients (or any clients). In such a situation, it is in fact entirely rational to develop a lightweight, low cost UI that a non-technical person can commit to, i.e. sign a contract. The developer can then go off and implement it with a very clear legal case if the client then chooses not to pay because "its not what we wanted". Its not what I do, and I know that many here take a more involved approach to their clients, but its undeniable that it is a successful business model, and in some cases I believe it can produce some result where otherwise there might be none. Equally I'm sure it produces results that are ultimately not used, but where the company still gets paid. [1] http://clientsfromhell.net/ http://clientsfromhell.net/

Morendil 15y ago

What I love best is this testimonial praising the book: > Helms and Valberg lay out an innovative methodology that finally delivers on the promise of Agile Development.

reledi 15y ago

Epicenter is sending out some annoyed tweets while defending the AgileUX movement. They claim their process is nothing like waterfall as it focuses on iterative UX prototyping. https://twitter.com/epicenternyc https://twitter.com/epicenternyc