14 ms·
In addition to the difficulty in making a meaningful estimate, I'm frustrated by how often management really wants to hear a particular answer and won't settle
by todd8 7y ago
In addition to the difficulty in making a meaningful estimate, I'm frustrated by how often management really wants to hear a particular answer and won't settle for anything but that answer. It can go like this:
1. Developers size development of X and says it will take roughly 12 months.
2. Management says the rest of the organization is going into system test in 9 months and needs X finished by then. Couldn't there be some way of speeding up the development of X without impacting the rest of the organization?
3. X's developers say no, not really.
Now management tries one or more of the following:
-- find someone else to size the work that X's developers will be expected to do
-- hire some outside "expert" to size X
-- hire contract programmers that claim to be experts in X that will join the X team
-- suggest reduced functionality for X
-- propose some modified "streamlined" component testing for X
-- promise to provide X's required dependencies ahead of their scheduled completion dates so X's development won't be gated by these requirements
Now jump back to step 1. Repeat until X's team relents and says that maybe, just perhaps they might be able to finish X in 9 months if everything goes perfectly even though the company has never done X before
This is now passed up the management chain and it becomes part of the official overall system's schedule that planning, marketing, sales, finance, etc. is depending on.
Iterating over all of these estimates is a big waste of time. Management has already decided that they want X in the system and will keep pushing until an estimate comes back that they accept.
If X's team is lucky, some other team will fail to make their estimated completion date and X will end up with the 12 months it might take to finish X. Every team in the organization is hoping that it will be a different team that first has to admit that they will not make their date. This causes a kind of game of chicken where every manager is unwilling to be the first to admit that their team is going to miss it date. Consequently, every date in the organization cannot be relied upon. The distributed file system needs the TCP stack to be finished on time, but the TCP stack needs the ethernet device drivers to be finished on time and no one will admit slippage of any dates first.
- tra3 7y ago> -- suggest reduced functionality for X Limiting the scope in a reasonable matter should reduce dev time, no? Assuming it's a true reduction in scope and not just lipstick on a pig..
- todd8 7y agoYeah, I thought that point might be confusing because I wasn't clear. You're right limiting the scope could reduce dev time and it might often be a welcome suggestion. It doesn't always go that way though and some proposals for modifying the functionality are costly because they can require re-architecting the design even before development starts. Usually, lightening the ship by throwing functionality overboard in a panic doesn't happen until around half way through a project, but what I was referring to was the sort of impractical proposals that come from non-developers about how to reduce development time. "Couldn't we remove the ability to customize user icons--everyone in the icon based user view can have the same icon." Okay, why have icons at all if every icon is identical? "Deadlock, what's that?, do we really have to detect it in the first release?" Hmm... "Can we leave out distributed shared virtual memory segments?" They weren't included in the original sizing "Do we have to do persistent client caching?" Well then we will be no better than competing products. "Does X have to run over both UDP and TCP?" That was originally a requirement. We can go back and examine that in light of other parts of the system depending on X.