3 ms·
Trying to prove the impossibility of something that is never going to go away as a requirement isn't very useful. An alternative would be to describe potential
by Dr_tldr 11y ago
Trying to prove the impossibility of something that is never going to go away as a requirement isn't very useful.
An alternative would be to describe potential break-points and conditionals in the planning process. For instance, if a third party library can help you with some core functionality, it takes a few hours to investigate and an hour to implement.
But if it's not going to work for whatever reason, then you know you have to make your own, and the initial implementation could range from 4-6 weeks.
If you say "this will take either 4 hours or 4-6 weeks", that's far more useful and acceptable to management than saying "this will take somewhere between 4 hours and 6 weeks.
No one sane is asking for exact estimates, and no one smart is promising a hard deadline based on the assumption that nothing goes wrong. A good engineer will pad their estimate slightly for the same reason that airplanes carry more fuel than the exact amount they need to reach their destination. It's not a deceptive or inefficient practice, it's managing uncertainty.
- thwarted 11y agoNo one sane is asking for exact estimates … It's not a deceptive or inefficient practice, it's managing uncertainty. Part of the issue is that the asking for estimates ends up getting turned into exacting time requirements as an attempt to control and manage uncertainty. And often, many of the people who turn estimates into requirements are, arguably, insane, because they are trying to manage the uncertainty in the wrong way.
- Gibbon1 11y agoI've taken to just telling my boss whether I think something is 'just work', 'tricky' or 'hard'. And about howm much of that he's asking for, Just Work: Means are the pieces are there to do whats wanted. Tricky: Means I need to create something from scratch or modify two or more modules. Hard: Anything to do with timing, interrupts, or that involves re-organizing swaths of unrelated code. Hard2: I have to learn a new language, frame-work, microprocessor, etc.