3 ms·

> When I tell some middle managers that I don't know exactly how long a software project will take they insist on endless planning meetings that hold up work ev

> When I tell some middle managers that I don't know exactly how long a software project will take they insist on endless planning meetings that hold up work even more. It's middle management's job to come up with the estimate and give that to upper management. They should not be asking team leads for project-level estimates, team leads are too close to see the forest for the trees. Any time a manager asks me for a number, I ask them to try to come up with one, because their guess is as good as mine, so he might as well come up with it. To management thinking, not knowing how long something is going to take is indicative of not understanding the problem enough. The solution to a lack of understanding is to get the right people in the room together to articulate what they know about it, figure out what's missing, and work out a correcting plan. In other words, a meeting. What's different about software development is that it more resembles research than manufacturing. If you were to ask Thomas Edison while he was testing thousands of materials for filaments how long it was going to take before he has the next light bulb, he'd have angrily thrown you out of the room. Yet we expect programmers to be able to answer that question all the time. The best estimate you'd get for when Edison would be done would be from someone close to him, but not actually working with him, say his secretary or wife. They'd be able to notice all the little things that he can't because he's not paying attention to them. So in software development, you'd ask the lowest level manager, rather than coder, for a ballpark number. All that person needs to do is look over the history of the group and come up with a number in line with other projects with similar scopes. If there's no project with a similar scope, then a meeting or two is needed in order to work out how to break up the project into more-manageable chunks.

maxxxxx 10y ago
It doesn't make a difference if you ask the coder, the secretary or some manager as long as they are allowed to give a ballpark estimate. That's easy. The problem starts once somebody doesn't accept that ballpark number and wants more precise data. Then you start pouring over velocity data and define the project architecture to a level you can't reasonably know at this stage. The solution usually is to make up some stuff but tell people about some nonsense methodology you used. It works but it's just lying. It would be much better if management methodologies would be able to accept uncertainty. Agile was one way to do this but it has evolved into a micromanagement tool.
- vinceguidry 10y ago
  > The problem starts once somebody doesn't accept that ballpark number and wants more precise data. That's crappy management. If my boss did that to me, it's time for a closed-door meeting where we have a come-to-Jesus on how software development is conducted. If I can't show them the light, I start sending out resumes because my working relationship with my boss is trashed and life is only going to get more painful over time.

maxxxxx 10y ago

It doesn't make a difference if you ask the coder, the secretary or some manager as long as they are allowed to give a ballpark estimate. That's easy. The problem starts once somebody doesn't accept that ballpark number and wants more precise data. Then you start pouring over velocity data and define the project architecture to a level you can't reasonably know at this stage. The solution usually is to make up some stuff but tell people about some nonsense methodology you used. It works but it's just lying. It would be much better if management methodologies would be able to accept uncertainty. Agile was one way to do this but it has evolved into a micromanagement tool.

vinceguidry 10y ago
> The problem starts once somebody doesn't accept that ballpark number and wants more precise data. That's crappy management. If my boss did that to me, it's time for a closed-door meeting where we have a come-to-Jesus on how software development is conducted. If I can't show them the light, I start sending out resumes because my working relationship with my boss is trashed and life is only going to get more painful over time.