Re:The Eternal Struggle Between Business and Programmers
by etler on Thursday May 15, 2014 @01:12PM
(#7750790)
I think a big part of the problem is that nobody ever teaches developers how to estimate and they are almost always wrong. A typical scenario is; PM describes a feature, asks for an estimate, and the developer gives it to him, right then and there. What's wrong with that? The developer hasn't done any research or exploration into the problem at all, and has no idea what he's talking about.
When you think of a time estimate, you're going to come up with a time assuming that the problem can be solved in the most obvious way, and that's because we can't possibly know about the problems we don't know about. It's not a terrible crime to not know things you don't know, but it is bad to make time estimates on things we don't know.
The correct answer is "give me a few hours to a day to look into the problem and I'll let you know how long I think it will take". The amount of time it takes for discovery depends on how big the feature is of course, but the point is you need to get your feet wet to determine what unknowns there might be, and you shouldn't give an estimate until you have done that.
Re:The Eternal Struggle Between Business and Programmers
by bippi on Thursday May 15, 2014 @02:06PM
(#7751124)
I applaud the thought, but then they have to have an estimate of how long the estimate will take... which often ends-up wrong.
Re:The Eternal Struggle Between Business and Programmers
by etler on Thursday May 15, 2014 @03:33PM
(#7751673)
That's true :) But at least the absolute amount wrong will be hours or days, instead of weeks or months. Also, you can leave it a bit more vague and just say "I need to explore the problem space a bit before giving an estimate".
* Management needs to get over itself and have a true vision beyond, "omg competitors are making money...more features!" that it conveys to everyone.
* The businesspeople need to absorb some of management's anxiety (and their own) on behalf of devs, and communicate with customers to ensure the vision aligns with what they want.
* The developers need to stop whining, up their game and go a bit slower so they don't get themselves in these situations to begin with. Give them what they need (quality code) not what they want ("anything that works NOW!!").
The business world seems rife with people who are purely reactionary, and yet still have the gall to wonder why they cannot innovate: "We don't have money for R&D!" OK, you don't have money for growth then.