Hacker News new | past | comments | ask | show | jobs | submit login

Waterfall might have been a straw man but SADT and other structured design principles put an unbelievable amount of dependency on diagrammatic and black box formalised boundaries of flow. All done up front.

People mocked things and prototyped things but I sat beside people who worked for 2 years or more on wall sized collections of ring binders of requirements specifications and flow charts, to end in acrimonious lawsuits.

I do kind of hate agile language. It's smug. But I love rapid prototypes and sprints.




OTOH, I've been in that situation too, and it was successful. The International Space Station has not yet fallen out of the sky. There are situations where waterfall is appropriate.


I am curious if this is usually argued. I thought it that was generally held that agile and similar methodologies at least in the sense that sprints are defined in days/weeks and not months/years is for use cases where the product doesn't have well defined specifications.


And yet the ISS has still had many bits added on, replaced, upgraded and modified. They just work to far, far higher standards than almost any company will pay for because they know if it goes wrong some very high profile people get dead.


In my field (troubleshooting for enterprises), I encounter, literally every day, prototypes (rapidly thrown together things that 'work-ish') in production and spewing bugs. I wonder where these companies are that actually toss the prototype and do it proper afterwards. Never seen it live, only on paper.


I've done many, many Proofs of Concept that were thrown out after exploration to make way for properly written production code. It's part of any new greenfield project I work at, we do a rapid prototype to validate some early design, learn from it and throw it out.

My field is not enterprises though, I worked all of my 20+ years career at tech companies of different sizes (from startups to 10k+ people orgs), startups and smaller companies usually will throw a PoC into production, and call it "tech debt" for later, larger orgs tend to avoid that since they've been previously burnt by the maintenance burden of poorly designed code in production (usually on their startup-ish phase).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: