Comment by zippergz | Hacker News Reader

Comment by zippergz | Hacker News Reader

Parent Full thread

I think expecting business to know what they want is a mistake.

I'm not much of an agile true believer, but as a former developer who is now "management" (shudder), I have never-ending frustration when teams expect full, perfect, set-in-stone requirements from day 1. When you're developing a new product in a new field, that's not how it works. We have to build something that minimally works, get it in front of real customers, and then make adjustments based on their reaction. Lather, rinse, repeat. This isn't "management can't make up their minds." This is "management are not clairvoyant."

To those who hate requirements changes, I'd love to know how you are able to determine with 100% certainty the exact product the market wants before you build it. If you can do that consistently, you should be a billionaire.

If you do understand that we don't know for sure what needs to be built from the beginning, you have two options. First, I can give you my current best guess at what we need to build, and we can work together to figure out what the right starting point (mvp) is, with the understanding that the rest may change later. Or I can figure out the mvp myself, and only tell you that, preventing the situation in which I told you about something that later has to change, but also robbing you of the opportunity to see the big picture and contribute to the plan. Which do you prefer?

I think the main issue most devs struggle with is not the changing requirements but that the timelines are not adjusted accordingly and have to be swallowed by the dev with overtime. And in most cases when there is some adjustments it's not nearly enough to cover the actual costs. If that was somehow resolved I think the vast majority of devs would be fine with changing requirements. Problem is I don't think there is an easy way because most non-dev don't truly understand the costs involved.

Fr example can u imagine telling a plumber no the bathroom is now going to be 30 feet to the left. The plumber says ok but that will cost u a week of work. How many people would say no, u have 1 day to do it and u will be held accountable for my estimate and not ur estimate because I don't trust u when u say a week. Now assume the walls are closed and it's only after u open them u learn there are other issues. Doesn't matter, one day. This is what most de s deal with. I assume ur not like this but this is how most devs have to work. It's frustrating. If u would be given the week then u would be fine, but instead ur told the timeline and/or cost. U may even be told no u can't use those tools they r too expensive, but u need to complete the task in the faster then even people who can use the tools.

My whole point is it's often not the change requests that are the issue, it's what it entails, in that the schedule and costs are not adjusted fairly.

Exactly.

That said, I think "give us the perfect requirements up front" is a reasonable defensive reaction. Because the first thing a lot of developers get asked is "When can you have this done?"

In most places, if the (made up, arbitrary) deadline is not hit, it's not managers who say, "Damn, our bad; we should have been clearer about what we were asking for." It's almost always an inquisition into either a) why the estimates were wrong, or b) what's wrong with the developers that they aren't delivering on time.

I now have a bag of tricks for keeping this kind of trouble to a minimum. But I think managers and execs have to stop asking, "When, to the exact hour, will this (hazy and ever-changing) thing be done?" It's not a sensible question, and if we pile blame culture on top of that, it's no wonder most projects quickly go off the rails.

Reply on news.ycombinator.com