As a community we need to get away from [making shit up]. If we don't know, we don't know, and we need to say it.
All too often, when we do say it, managers just get annoyed and demand it be done by an arbitrary deadline; since we don't know how long it will take, we're not in a position to justify why it will take longer than that arbitrary deadline. The decision gets made either by "this is when it's needed" or "make up something so he'll stop pestering us", the date gets etched in stone, the particular scenario is forgotten, and when the date is missed everyone looks bad and gets annoyed.
Managers need to know how long things will take. Fair enough, there's more to most projects than just development, and it all must be scheduled to come together in a sensible workable timeframe.
The problem is it's still a fast-changing discipline, with the unknowns dominating the knowns. The biggest known is construction time: most disciplines have a construction/distribution period long enough that it can cover/buffer for variation in the design phase; in software, the construction/distribution period is nigh unto instant (compilation), so design can't hide behind any other phase. It's all design, usually entailing something significant designers have never dealt with before. It's not, say, a bridge where all the basic materials & mechanisms are well understood, predictable, and have a long construction period which can run parallel to at least some of the design phase.
> The problem is it's still a fast-changing discipline, with the unknowns dominating the knowns. The biggest known is construction time: most disciplines have a construction/distribution period long enough that it can cover/buffer for variation in the design phase; in software, the construction/distribution period is nigh unto instant (compilation), so design can't hide behind any other phase. It's all design, usually entailing something significant designers have never dealt with before.
This: an estimate to build software before the development has started (even assuming that the business requirements are frozen) isn't equivalent to an estimate to build a building once the design is set, its equivalent to an estimate of how long it will take to design and build a building once some of the basic objective parameters are set (like how big the footprint it can have, how much office space it needs to provide, etc.) but before the actual design has started.
In this situation I tend to follow the Montgomery Scott Miracle Worker Rule(tm). Come up with a nice, comfortable number in your head, pad it out a little if necessary so it's a nice round number, then multiply by 4.
The only thing that worries me with this technique (as tempting as it is), is that I've seen teams where the work will dramatically slow down because they're trying to "fit" to the deadline. Getting it done as fast as possible and early only leads to more work for more people.
My solution to this: research. When I don't know how long something will take, I go find the basic ingredients, talk to people with experience and get back to management in an hour.
I find it's not necessary to push back like that on every project, and the more discovery about these things you do, the easier it gets.
All too often, when we do say it, managers just get annoyed and demand it be done by an arbitrary deadline; since we don't know how long it will take, we're not in a position to justify why it will take longer than that arbitrary deadline. The decision gets made either by "this is when it's needed" or "make up something so he'll stop pestering us", the date gets etched in stone, the particular scenario is forgotten, and when the date is missed everyone looks bad and gets annoyed.
Managers need to know how long things will take. Fair enough, there's more to most projects than just development, and it all must be scheduled to come together in a sensible workable timeframe.
The problem is it's still a fast-changing discipline, with the unknowns dominating the knowns. The biggest known is construction time: most disciplines have a construction/distribution period long enough that it can cover/buffer for variation in the design phase; in software, the construction/distribution period is nigh unto instant (compilation), so design can't hide behind any other phase. It's all design, usually entailing something significant designers have never dealt with before. It's not, say, a bridge where all the basic materials & mechanisms are well understood, predictable, and have a long construction period which can run parallel to at least some of the design phase.