alt Hacker News> Requirements gathering: fluid, not dictated
> Requirements used to be handed down. A PM writes a PRD, engineers estimate it, and the spec gets frozen before a line of code is written. That made sense when building was expensive. When every feature took weeks, you had to decide upfront what to build.
In the 20 years I've worked in software. I've never even seen a shop that works this way. From 20 person teams to 10,000 employee companies. Maybe I've been lucky. but to me it reads as a straw man. Something to punch against that doesn't really exist.
> Design used to be something you did before writing code. You’d whiteboard the architecture, debate trade-offs, draw boxes and arrows, then go implement it.
Again, I've never seen this. Usually it'd be a senior engineer who spun up a project, implemented a proof of concept, and then mid and junior staff would be onboard and work within the project's design patterns, occasionally refactoring the design if it outgrew its original footprint.
I don't necessarily disagree with the agent workflow, but we should compare it to what actually proceeded it, not some imagined dummy process that never really existed. It weakens, not strengthens, the piece.
Note: I'm sure you experienced these, but have you considered that you're an edge case? I've equally considered that perhaps I've just been extraordinary fortunate in my career.
Replies
In the 30 years I've worked in software, I've seen more than one shop that worked this way. Then "eXtreme Programming" and Scrum rose up and morged into "agile", and that pretty much went away.
I’m working in the industry since 1999, spent a lot of time in regulated industries and fully agree with you, waterfall was never the process. The actual process could generate a lot of artifacts, but it was always async, not strict happens-before relationship.
Requirements handed down - never seen it in 25 years. The requirements are always fluid, by definition. At best, you get a wish list which needs to be ammended with reality. If you have completely static requirements, you don't need an engineer! You just do it. Engineering IS refining the requirements according to empirical data.
Once you have requirements that are correct (for all well-defined definitions of "correct"), the code implementation is so trival that an LLM can do it :-)
Same here. It’s like the author just finishes their Software Project Management module at uni, saw AI and had their mind blown without ever learning this thing called “The Agile Manifesto” exists!
Remember, Waterfall model was AFAIK originally just an example of pathologically bad managed project in a conference talk :V
I’ve seen this at more than one company.
> In the 20 years I've worked in software. I've never even seen a shop that works this way. From 20 person teams to 10,000 employee companies. Maybe I've been lucky. but to me it reads as a straw man. Something to punch against that doesn't really exist
30 years ago it was the norm. It really is true that the industry (standard) has shifted a lot in that time.
But I work at a place like this right now. I was hired by the new CTO to help them change this, having spent the previous 20 years actively avoiding places just like this.
Project-based planning by a roomful of not-technical people: Funding, scope, design, shape of team, deadlines, tech stacks, vendors etc. all "locked in" before any engineer is even approached, let alone asked for input.
I cannot overstate how uncanny it feels to be working here - like I have actually time travelled back to the 90s.