3 ms·
I must urge any serious developer who has read that article to immediately forget about it! Let's begin with the first phrase, "Software estimate". An estimat
by segmondy 10y ago
I must urge any serious developer who has read that article to immediately forget about it!
Let's begin with the first phrase, "Software estimate". An estimate is an approximation. An approximation is an educated guess. So if someone said to you, "Please make an educated guess on when the software you are working on will be completed" To say it would be impossible would be the most absurd thing!
To make an educated guess, You would have to break down the tasks into manageable chunks that you can clearly reason about. Once you have your chunks of task, you will have knows, unknowns, some with risks or not, some that are complex or easy, etc. The problem with estimates is the unknown. If you are constructing software for an entity, then you must not approach it as an R&D, but rather, as a possible Research THEN Development. All your unknowns should be figured out at the research phase, then you estimate the development, else you should fight to remove those unknown tasks from the project.
Think about it, do you get asked for "Software research estimate" or "Software development estimate"? It's the latter, but most developers make the mistake of offering their estimate across both R&D. The really beneficial thing to developers about estimates if they do take it serious, is that it forces you to stop, think, design, and think again before coding.
The biggest concerns for developers is that estimates TURN into deadlines. This is a legitimate concern, but nevertheless this doesn't invalidate your estimate, which is nothing but an approximation. The other concern is that feature/scope creep into the project really puts a wide gap between the estimate and completion date. This again is true, remember your estimate was for the original requirements. So what are you to do as a developer? You must teach your manager if they don't know or whomever you are working for the difference between estimates and deadlines. You must also learn to keep feature creeps at bay or estimate those new features anytime they are added and adjust your estimate accordingly.
If you are a non manager or business. Please do think about this from their point of view. Projects have costs, which we can quickly approximate via cost of people working on it multiplied by the duration of the project. Part of running a business is managing your cash flow, knowing if you should spend or not. Without having an estimate of a duration of the project. How can businesses make decisions on which projects to fund? If you have a startup and $100,000 in cash. No income yet, 5 programmers that you pay $5,000 a month. Would you let them work on a project with no completion date, 1 yr estimate or 2 months estimate?