I really found this quote illuminating:
> When executives ask for an “estimate,” they’re often asking for a commitment or for a plan to meet a target. The distinctions between estimates, targets, and commitments are critical to understanding what an estimate is, what an estimate is not, and how to make your estimates better.
It's a pretty deep book that discusses everything around estimating:
- how to estimate and what things get missed during estimation
- why estimates gets missed
Really recommended.
[0]: https://www.amazon.com/Software-Estimation-Demystifying-Deve...
This lesson was brought home for me by https://www.amazon.com/Software-Estimation-Demystifying-Deve... explaining why the COCOMO model didn't work well in practice as an estimation technique, despite their having collected a lot of good data on what affects schedule.
This lesson is one that the EA community broadly seems to ignore.
A very good book on software estimation is: https://www.amazon.com/Software-Estimation-Demystifying-Deve...
The guy basically listed excuses for padding the estimate.
Steve McConnell wrote a book about it, using a much more rigorous scientific methodology[0]. He has also written some other stuff about it[1].
This one is really the big one:
"9. Both estimation and control are needed to achieve predictability. "
In my experience, we can accurately estimate software projects that have iron-fisted control. No deviation from the plan. If we use quality-first techniques, like TDD, we can do a fairly good job of hitting targets.
Also in my experience, this results in software that no one wants to use. It doesn't crash, ticks off the punchlist, and basically sucks.
I avoid estimates like the plague (a rare luxury, but I can do it). I like to "wander down the garden path, and see what sights there are," so to speak. I call it "paving the bare spots."[2]
It results in software that comes very close to the user/stakeholder "sweet spot," with great quality. It also tends to come together fairly quickly, and allows for excellent early project visibility.
But that won't work, beyond a fairly humble scope.
[0] https://www.amazon.com/Software-Estimation-Demystifying-Deve...
[1] https://stevemcconnell.com/17-theses-software-estimation/
[2] https://littlegreenviper.com/miscellany/the-road-most-travel...
https://www.amazon.com/Software-Estimation-Demystifying-Deve...
and
https://www.amazon.com/Rapid-Development-Taming-Software-Sch...
Also think: if the business does project A, how much money does that make for us or save for us? From a developer standpoint I have gotten the business people to tell me a value that is a fraction of the cost of the product. You fold that one and free up resources for project B which is the other way around.
The problem is that on a non-trivial project, these breakdowns are guesses which carry considerable uncertainty. And the less you know, the more the unknown-unknowns get you. If you write a detailed breakdown of a major piece of software before writing a line of code, at the end of the project you will look back and laugh and laugh at your own innocence.
As just one random top-of-mind example, consider Carmack writing Doom's rendering engine[2]. He tried several approaches that didn't work before striking the right balance with pre-computed BSPs. Some of the things he tried were fundamentally good ideas and would later be used for different games - but didn't work on the hardware of the times. How do you estimate something like that? "I'm going to spend a month on my first approach. That could be one month or two. If that doesn't work, (50% chance), I'll read research papers and textbooks (1 week - 3 months) until I find a promising technique. Then I try the most promising of these; since this is an approach I haven't even read about yet, it could be one week to implement, or six months. And there's some chance that will fail to and I'll have to do it again." The final estimate is anywhere from one month to a year. You just can't know.
[1]: https://www.amazon.com/Software-Estimation-Demystifying-Deve...
Two books help with methods of doing this.
Rapid Development: Taming Wild Software Schedules: https://www.amazon.com/Rapid-Development-Taming-Software-Sch...
Software Estimation: Demystifying the Black Art https://www.amazon.com/Software-Estimation-Demystifying-Deve...
This likely does mean you'll need to be allowed to deploy automated test cases, develop documentation and the entire nine yards, because it's going to be far harder to hit any reasonable deadline if you don't have a known development pipeline.
You'll need to reduce your uncertainty as much as you can to even have a chance - and even then, things will still blindside you and double (or more) the actual vs. the original estimate.
Going to read it. thanks.
If you'd genuinely like to learn more about estimating software projects and when you can do so more or less reliably, Steve McConnell's Software Estimation: Demystifying the Black Art provides a great survey of techniques.
https://www.amazon.com/Software-Estimation-Demystifying-Deve...
http://amazon.com/Software-Estimation-Demystifying-Developer...
(if yes, then why isn't it on your list!?)
Some examples:
- Team or company meetings
- Team member sick days, holidays, vacations
- Bugs in third party software
- Maintenance of previous systems
- Maintenance of build automation
- Demos
- Interviews
- ...
In the painting example, the moving of the furniture was something I overlooked, despite having made the effort to carefully think of all tasks. A estimation checklist built up from previous painting projects could have triggered me to consider this task.
[1] http://www.amazon.com/Software-Estimation-Demystifying-Devel...
http://www.amazon.com/Rapid-Development-Taming-Software-Sche...
and
http://www.amazon.com/Software-Estimation-Demystifying-Devel...
If you want to get deeper into project management I suggest that you become a member of the PMI and possibly get certification from them. The training and testing are rigorous and it is a certification that means something both from the knowledge you get and the benefit of having it on your resume.
Here are some challenges that come to mind in software estimation:
1. Estimates are almost always done too quickly, with too little information. If you can wait, spend more time, or reduce the unknowns, do so. If nothing else give it an extra fifteen minutes. If you can say "I'll get back to you with an estimate by ..." (e.g. tomorrow or end of day) that's even better.
2. Estimates are ranges, a probability that the work will be done across a range of time. but are often given as a specific date or amount (e.g. "It will be done tuesday/take 5 working days"). Early or quick estimates may be ranges of 15x or more (e,g, "it will be eight hours to three full work weeks"). Don't be afraid to capture that ambiguity in a range. Others may not understand ranges, so give them the high end if needed, but at least be aware that ranges exist. Often ranges, or high estimates get push back. This is your opportunity to specify what questions need answers, what requirements need refined, and what areas need more design and architecture to reduce ambiguity. These things can reduce ranges of estimates.
3. Know the difference between estimates, targets, goals, and commitments. Confusion between these leads to miscommunication and frustration. Often we'll make a guess like "maybe two weeks" which is a wild instant estimate, and others will see how nicely that lines up with their target date, and believe you have committed to that goal. Commitments should be explicit, and part of your process.
4. Do not negotiate estimates. Managers are trained to negotiate, and a naive manager will almost always reduce estimates through negotiation, which is a distortion of reality. Developers should collect the information they need about the requirements, ask questions, then produce their estimate in isolation, and refuse to change it. The way to change an estimate is to change the requirements, often addressing ambiguity and questions, and re-estimate the work given the new information. This is hard to do, because a "better" timeline can make everyone feel better in the moment, but will lead to problems later.
5. Renegotiate when change happens, or when you are in danger of failing a commitment. This one answers half of the original question, to my mind. If you didn't make a clear commitment, or requirements are changing with out any renegotiation, you have to fix those first. After that, keep a close eye on scope creep, and changes. Change happens, accept that, but make sure that those you have commitments to understand that change has impact on your commitments, and you can either commit to the original work and timeline, or you can commit to the new work, and a new timeline. Holding you to new work on an original timeline is not fair to you, and not a problem to be solved at the developer level. This one can be quite challenging, some people use "change management", itemized / ticket based change requests, even explicit signoffs. If you have trouble here, find what works for you.
6. Learn from history. You won't get it right. A lot. Keep track of how you are doing, improve processes and spend more time refining requirements/acceptance criteria etc. Make sure commitments are negotiated and explicitly agreed to. Keep learning.
7. You will make mistakes. If you uncover new questions, requirements, found work, it was in a certain sense an estimating error, but it has a different fix. If you had a reasonable view of the work to a fair level of detail and spent reasonable time on the estimate, and are still missing your commitment, you have made a mistake. That's OK, especially early on, or in new areas for you, if a team has shifted etc. The answer is, communicate. Let your manager know immediately, as soon as you realize it, that you feel you are at risk of failing a commitment, and you need to revisit. From there, you can investigate the new work, or re-estimate based on your increased understanding of the problem. Perhaps note some data for your historical tracking. Learn. Next time, make a better estimate. It does feel bad to miss a commitment, or even to not make a deadline that someone else set up. That's very human. The way to feel better about it, is to get better at it.
The above is based on my decade of experience as a software developer, and a solid foundation from Software Estimation: Demystifying the Black Art, By Steve McConnell http://www.amazon.com/Software-Estimation-Demystifying-Devel...
I highly recommend the book as a learning resource, and having the whole team, managers included, read at least the first portions of it. It also has specific tools for various estimating challenges.
Estimates, plans and commitments are three different things (see http://www.amazon.com/Software-Estimation-Demystifying-Pract..., which is the best book I've read on the subject).
The problem with estimation in many cases is that people who dictate requirements often dictate commitments as well, and do so without estimation-based feedback. In other words: "Your ten-week 'estimate' isn't acceptable; we have to have this done in seven!"
Why would software estimation matter? For many companies it matters a lot if you can announce something in time for Christmas. Or you might have to hit a deadline for compliance with a legal contract. Or you may be trying to prioritize two different possible products - without a sense of the effort involved you're lacking one of the parameters you need for such an estimation.
That doesn't mean that you always estimate. If the value proposition is clear enough, you're going to work on it until you're done and then you will be very happy. But the real world does not usually work like that.
* Mike Cohn resources were the most helpful to me:
- free presentations around estimating and planning (eg: http://www.mountaingoatsoftware.com/presentations/131-agile-... and others on the same site)
- the "Agile Estimating and Planning" book (http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp...)
- Mike Cohn "Agile Estimating and Planning" course (2 days) was worth taking
* Software estimation: demystifying the black art (http://www.amazon.com/Software-Estimation-Demystifying-Pract...) is a very useful book too
* For lightweight project management tool: I use a mixture of Acunote (for estimating and burndown chart - I even generate my quotes out of it using Ruby and Prawn) and Freckle to monitor the time spent.
I tried many other tools (including Mingle, Pivotal, etc...) but Acunote is the only one that works well for us.
Never give off-the-cuff estimates, no matter who is asking.
Bosses and project managers tend to hold you to those estimates regardless of the caveats you give. Also, of course, an off-the-cuff estimate is very likely to be more wrong than a detailed estimate.
Here's why this is relevant to the OP: by withholding your estimate until you've had a chance to give it enough thought, you relieve the social pressure that is created in the moment by the project manager or boss who is saying, "we must have it and it must be easy, can you do it today?" Just say, "let me get back to you," and follow up with a reasonable compromise that is healthy for the project and meets the business goal.
Never give off-the-cuff estimates, no matter who is asking.
[1] http://www.amazon.com/Software-Estimation-Demystifying-Pract...
- http://www.mountaingoatsoftware.com/books/1-agile-estimating... (with free chapters; also read the various presentations on the site)
- http://www.amazon.com/Software-Estimation-Demystifying-Pract...
One key point is to really understand what is risky in terms of estimating (either technically or politically or because it's too vague).
At some point, you can really become accurate as long as the scope is well understood.
In my case, the Fred Brooks technique does not apply: my last customer iteration was 70% infrastructure, 20% code, 10% pm. The one before was 70% code, 10% infrastructure, 10% documentation, 10% pm.
I do think this approach where there are lots of specialties (Software Engineering, Game Prgramming, Systems Programming, etc) allows people to get experience and training relevant to where they're going in life.
All that said: I really really really want to see realistic mentored debugging go on in a CS program. I want to see 2 students and one experienced adult, sit down and learn next to someone the ins and out of all the modern debugging techniques (debuggers, binary search, profilers, memory leak detectors, etc). None of the classes had anything like that, and that was the biggest thing missing that comes to mind.
The second biggest thing is realistic estimation methods! Until I read a book on it and practiced a lot, I was horrible at it. Very little was taught on actual methods to make useful estimations.
(Here is a non-aff link to the book who's material I'd like to see covered in a college CS curriculum): http://www.amazon.com/Software-Estimation-Demystifying-Pract...
It is a teachable trait, arguably what very selective schools with hard grading curves teaching difficult things teach people to develop (as you have to determine what you don't know to pass/excel/etc there).
I've always personally believed the test: "What would you need to get going on these 5 projects?" Is a great question. If talking about researching X Y or Z don't come out of the candidate's mouth (and it's not an old solved problem, like self-contained embedded C code), you mark them down as less meta-knowledgeable. (Doesn't mean unhireable, but you don't want them in highly independent positions or constantly learning new things; people with low meta knowledge appear to actually be quite happy in places that high meta people hate, such as long term maintenance programming).
In software particularly, study of estimation (and it's continual use) can teach people the practice of evaluating all risks, including metaknowledge. I like the book: http://www.amazon.com/Software-Estimation-Demystifying-Pract... (non-aff link) for getting people going with the practice.
http://www.amazon.com/Software-Estimation-Demystifying-Pract...
https://www.amazon.com/Software-Estimation-Demystifying-Deve...
?