3 ms·
If you can't ESTIMATE your software project, then you have no idea what you're doing. An estimate is NOT A DATE, an estimate is a DURATION. If you estimate 50
by segmondy 7y ago
If you can't ESTIMATE your software project, then you have no idea what you're doing.
An estimate is NOT A DATE, an estimate is a DURATION.
If you estimate 50hours and other things come up that eat into your time, you continually adjust the DATE, the duration shouldn't change. If you depend on an external sys and you estimate N hrs, but that system takes N+M hrs, then your duration date moves forward M hrs.
If there were unknowns, risks, as you uncover them, you move the date and if you communicated the unknowns and risks, then you can adjust the duration by adding the new info.
Ideally what you wish to do is eliminate all the unknowns and risk by NOT doing them. You're doing DEVELOPMENT not RESEARCH. Development is simply pulling in all your prior knowledge on how to solve problems and tacking similar or new problems.
Don't mix your R&D.
- QualityReboot 7y agoI don't understand how solving a new problem that you haven't solved before is somehow development instead of research. All software is research. If someone had already solved it and built it, you could just copy their solution. I've been doing dev work my whole life, and the only thing I can say about estimates is to underpromise and overdeliver.