Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sometimes it comes down to poorly understood user requirements, necessitating design work in the middle of a sprint, causing a cascade of other issues like new data models, different table relationships, updates to UI screens, and on and on. Agile might pride itself on being able to handle such things, but...it’s not. Nothing is. Poor planning, no matter the methodology, results in slow, cumbersome, error-prone execution and tons of rework, 100% of the time. This was not a meant to be a rant against Agile, but in BA (Before Agile) we spent a great deal of time in requirements gathering and architecture research, so that by the time we were ready to code, we could focus on the how and not the what. And damnit, in BA we had requirements documents that actually described what needed to be done. For sone reason that is probably a misunderstood principle of Agile, requirements are considered completely unnecessary or at best a waste of time. The prevailing attitude seems to be just build the darn software, we’ll figure out the requirements later. This is like trying to build a plane while on the runway with passengers trying to board and the control tower screaming at you to take off.


I don't know where you worked, but have I worked in a place that did a design document, dropped it off on my desk, and left me to work.

Them: "Why didn't you include the functionality to twiddle the foo?" Me: "What? I don't know what you are talking about." Them: "I swear it was in the design document, it's one of the most important features!" But it was not.

Every design document has flaws, and even if they are as accurate as possible, many projects had to be updated after the fact as even the designers themselves did not predict some of the functionality needed. I've found that when developing new things you need to have steady communication with the people who need to use it, to understand what they need and why.

For recreating old the things (CRUD apps and whatnot) I'm sure this is not nearly as important, but I have always wondered why recreating old software with modern tools has usually resulted in everyone just using the old software. I do know in one case I've done this, I was told not to include certain features because no one uses them... only to find our users not updating, because everyone needed those features. Some times even the vendors don't know what the customers want.


> And damnit, in BA we had requirements documents that actually described what needed to be done.

That’s some damn fine nostalgia juice you’re drinking there. Can I have some of that?

Me, I had the time and expense of requirements documents combined with the pleasure of them not actually describing what needed to be done.


All things considered, agile probably still produces results faster overall. Its like running the requirements gathering & software dev concurrently rather than serially.

Faster = cheaper. So the logic of economics dictates that is exactly what will happen, even if it is more stressful :/




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

Search: