Why Devs (Should) Like Estimates

As a Principal Web Developer at Stack Overflow and a long time Tech Lead, I learnt that accurate estimates were essential in order for a company to be healthy and productive. Over the years I have spent a good deal of time developing my theories for why estimates and breakdowns are so important, and crafting my own methodology for how best to go about doing them. 

Below, I attempt to distill the lessons I’ve learned so that others can experiment with and improve upon my techniques. Now, I should be clear, the advice below is what works for me. I’m sure there are different approaches that might work better for others. Feel free to share your favorite approach in the comments.

Why are devs asked for estimates?

The impetus to provide an estimate for development work most often comes from non-developer stakeholders in your organization. An estimate helps to plan and coordinate product releases, synchronize work with other teams, ensure that resources are allocated properly to meet the needs of the product, and of course to enable accurate billing of clients when your team has been hired to do a job for an outside company. 

Given that list, it’s clear there are many legitimate reasons why you will be asked for an estimate. And due to a number of reasons (guilt, good intentions, pressure from the estimate requestor) you might even give a best-guess estimate. However, as many of us have learned, while it is easy to give someone a number, it is much harder to give a number that is in any way accurate. And due to the dependencies that others put on the provided number, a bad estimate can sometimes do more damage than no estimate at all.

What a good estimate provides

By dint of its prerequisites (and the level of organization and planning they require), an accurate estimate will enable you to deliver your work with a high level of quality in the least amount of time. It will help you to avoid false starts and the pain of having to throw away code unnecessarily. It will help to minimize scope changes. It will allow you to structure and to plan out your work in the most efficient way that you can, and will also help all of the other stakeholders mentioned in the previous section out immensely. 

Estimating Rules

So how should you do estimates? Estimation technique is a personal decision that each dev has to make for themselves. Recommendations will be made below for different techniques that have worked for different people in the past to come up with the final estimate. 

That said, here are some guidelines that are important to follow (regardless of the estimation technique). 

Never write code unless you have a good understanding of what functionality is required

While this is not something that directly relates to making the actual estimate, it is at the top of the list because it is such an important factor in writing quality software that actually does what the client needs it to do. Beyond the benefit to others that an accurate estimate provides, the main artifact that an accurate estimate gives you is the confidence that you know what you are working on, that you have thought about the different issues that may arise with architecture and implementation, and that you have taken these into account in breaking down your work and making the estimate.

Always estimate off of a spec

An estimate that is not based off of a strong understanding of the functional requirements will most likely result in an inaccurate estimate, as it will not account for all of the required functionality. Even if there have been meetings to talk about what is needed, unless it is written down and all stakeholders have agreed on its contents, it should be assumed that one of the stakeholders understands the requirements differently from the others.

If the spec has unanswered questions, or missing details, don’t commit to an estimate for or work on that section

An important part of the spec-writing process is reviewing the spec and asking questions as needed. Take the time to cover edge cases and implementation details that will impact the functionality. Call out sections that are missing important details (these are often the most complicated sections on the spec). 

Spec-writing takes time, and sometimes there are requirements that are not understood until later on in a project. That is fine and acceptable. The consequence of this is that the incomplete sections in the spec cannot be given an accurate estimate.

If the estimator has not thoroughly reviewed the spec, the estimate will not be accurate

Without reviewing the spec, the estimator is simply not properly equipped to make an estimate for completing the functionality that is required by the client. There is no real way around this—coming up with an estimate in these circumstances has a very small chance of actually relating accurately to the work that needs to be done.

The developer doing the work should perform the estimate

An estimate that is made by someone other than the person who will be doing the work is much harder to get correct. Even if the estimate is based on a complete spec that the estimator understands, it will still have some major shortcomings: 

  • Every developer works at a different pace, so one dev’s estimates will normally not be transferable to a second developer.
  • Every developer will break down and plan their work differently.
  • Different devs have different sets of domain knowledge, which also makes time estimated to learn/understand consequences very different for changes (and if you don’t have the domain knowledge, be sure to account for the extra time needed in your estimate as well).
  • If the developer doesn’t do the estimate, they have missed out on the extremely valuable step of planning out the project execution, something that can contribute greatly to avoiding unnecessary work and delivering features on schedule.

Keep the spec and estimate up to date throughout the course of the project, including scope changes

Ideally, the spec and estimate should be kept up to date through the course of the project as requirements and scope changes. It will be indispensable for performing QA properly and will serve as a very handy reference for anyone who needs to learn more about the functionality in the future.

Discipline

Do not let yourself be bullied into giving a full estimate for sections that haven’t been properly defined

Once you reach a stage with stakeholders where people have bought in to having the developer be the author of the estimate, this can lead to a situation where pressure is exerted to commit to an estimate for work that has not yet been fully defined. This common scenario can happen with the best of intentions. Plans need to be made, and often they need to be made by those who do not have a direct way to move along the definition process. And when those plans rely on estimates, it can leave the developer in a hard place.

In this scenario, it is important to be very clear: an actionable estimate must be based on well-defined work. It is important to make this clear to the stakeholder. And while doing so, be sure to highlight that you want to give them a reliable estimate, and doing so without knowing the full scope of the work will almost surely result in an estimate that is not reliable. In cases of need, you can always provide a greatly inflated, worst-case-scenario estimate, but this should be avoided, and when you must, be sure to let the stakeholder know that the estimate itself can be updated and made more accurate once more details on project definition are known.

Do not mold an estimate to meet externally-dictated time expectations. Drop features instead.

Another uncomfortable scenario that can occur is when a stakeholder attempts to dictate what the estimate needs to be, based on external dependencies or other business requirements, even when this is at odds with the real estimate. The hope is that getting the developer to commit to this estimate will ensure that the work will be done within these time constraints (or if not, that the developer can be held responsible for missing the deadline). As should be clear by now, any estimate that is not based on a realistic breakdown of well-defined requirements should not be deemed reliable or, in fact, be given at all. In this scenario, the proper response is to negotiate scope for schedule. As in: if you want to release by this date, then we need to cut the amount of work that will need to be done. Hold firm and keep bringing the conversation back to your desire to provide an estimate that will be accurate and reliable for everyone involved.

Translating hours into days: be realistic

Your estimate should end up setting a number of hours to complete the defined tasks. For planning purposes, you will often be asked early on in a project how many days of coding will be required. I find it’s more accurate to create granular estimates in hours and to translate the total hours into a number of days. In doing so, be sure to factor in things like other duties (bug duty, other projects), management responsibilities, vacations, and holidays. Also be sure account for routine  tasks that the developer needs to do (meetings, email, spec reviews, planning). I have found that assuming any more than 6.5 hours of productive project work a day can result in a mismatch between productivity expectations and actual results. 

Make your breakdown and estimate public and ask for feedback

Once you have your breakdown and estimate complete, it is best to post it online and share it with your PM and team members. Even if they are less familiar with the details of the spec than you are, other people may see holes in your breakdown or may be able to raise questions about estimates for specific items that you had not thought about. Remember: it becomes exponentially more expensive to fix things the further along you get in a project. Changing a line on an estimate is cheap. Rewriting a module from the ground-up is not. Take the extra time to solicit feedback.

Posting estimates publicly (and keeping it up to date with regards to task completion) also makes you more accountable for your progress (in a good way). A responsible PM will check on your progress periodically, especially if it looks like things are stalled (a scenario where you should be in open communication with the PM anyway).

It is ok to give an estimate range along with a confidence scale

If the entire spec cannot be completed in time for the estimate, give a full estimate for parts where you can and range/confidence for sections where the spec is incomplete. Use your judgement: you might be asked for a 100% confidence estimate on a large project, but if the spec isn’t ready for that, then be clear about what your estimate covers. It is much better for everyone in the long run to say: 60-100 hours with 60% confidence than to say nothing or to make up an exact number without basing it on anything. And then as the spec becomes more complete, the estimate should follow suit.

Risk mitigation and accounting for iterations on larger projects

Large projects (arbitrary definition: projected to take over two months, though this can vary) come with their own set of challenges. They will have larger estimates (and therefore more opportunities to mess up the estimates), they will have more people relying on the projected release date for whatever their dependency is, they are more likely to have large specs where not all functionality is defined up front, and they are more likely (at least in some domains) to have cycles of release/iterate. How does one account for these in estimates?

While every project needs to be addressed based on its own needs, the general approach for large projects featuring iteration should be to use the guidelines stated above on both a macro and micro level. If the very large project has one section of work fully defined in the spec and the rest of it loosely defined, then make a breakdown and estimate for the first section. If a full estimate is needed for the entire project, then make a very conservative estimate for the whole thing based on what you know of the functionality, attach your assumptions and confidence in the number, and continue to pursue getting the entire spec completed and all of your questions answered. 

This also applies to iteration: if the project planning calls for a continuous release cycle, with features being constantly refined and redefined throughout the iterative process, this is something that by definition will be extremely challenging to accurately estimate up front, as at the starting point there is no defined functional requirement. In a situation like this, you just cannot be as confident in an estimate as you would be with a full functional specification. If this is the reality and you are requested to give an up front estimate, there is nothing to do but to estimate very conservatively for the ill-defined sections, noting your assumptions and confidence level. Unfortunately, these situations are sometimes unavoidable—what you can do to mitigate the potential damage of a bad estimate is to continue to pursue a full functional specification while being very clear about the limitations there are on any estimate that you provide such that all parties are as well-equipped as possible to deal with it.

Be sure to include time for pull requests, testing, and release issues 

This is something that is very easy to forget about, and leaving off time for pull request testing and product release (especially when these are non-trivial) can leave a sour taste in everyone’s mouth when features are delivered on time and then the last stage of QA and release end up dragging on and on. In scenarios where PRs are a required part of the process, and especially when they bottleneck on very busy reviewers, the time that they add to an estimate can be non-trivial. While it doesn’t necessarily add to the amount of developer time (though it could, based on the quantity of feedback), it will add to the delivery time. A responsible developer should take care to take these factors into account in their planning and when making commitments as to deliverables, based on the specifics of the project responsibilities (for example: who will be reviewing PRs, who owns QA, what will be involved with the release, etc).

Techniques

The best estimates involve breaking down the work to be performed into small tasks—the smaller the better. Estimate the tasks, break them down, and repeat until they get small enough. This is the essence of a very thorough and accurate method for estimation. Establish a goal for granularity. I recommend two hours maximum, and break down tasks until you hit that across the board. If you have a task over the threshold, break it down further. Then sum it all up. 

There are various tools that you can use to help for organizing this. I prefer using Trello cards (one per main task with a checklist for a subsection and checkboxes for granularity) though this does require manual calculation of hours. You can also use Excel, MS Project, FogBugz (or one of many other project-organization tools out there). The most important thing is that you use a tool that works for you and your process and that does not add organizational overhead.

There are other approaches to estimates out there (I go into more depth on estimation practices in this article). Especially in the agile world, from Planning Poker to many others. If this works for you and helps you to get an accurate estimate, then go for it. Just remember, it can be risky to rely on techniques that take the onus of estimation off of the developer who will be doing the actual work. 

Do you have thoughts on how best to provide estimates so developers and dev teams can work with the rest of their organization? Let us know your tips and tricks in the comments. 

We have something fun for ya. Our latest podcast episode is out! You can check out all our episodes here.

Author

Yaakov Ellis
Principal Web Developer, Community
Husband, father, learner, coder and nerd. Principal Web Developer on the Community Dev team, former Team Lead for Internal Dev at Stack Overflow.

Related Articles

Comments

  1. Excellent post Yaakov, thank you for sharing it!

    1. Yaakov Ellis says:

      Thanks Rafael!

  2. “The developer doing the work should perform the estimate”.

    I do not like this, in a team, anyone should be able to do any task. By assigning tasks beforehand make the plan very dependent on individuals. The team’s estimate should average out across tasks anyway.

    1. Yaakov Ellis says:

      Thanks for the comment Viktor.

      Part of the reason for the person who is actually doing the work to be the one to perform the estimate is that making a good estimate requires you to make a breakdown of the work, which requires you to confirm that you know about all of the things that are to be done, etc. And then to think through all of those steps. This exercise itself is often more valuable than the actual number that you end up with.

      While anyone should be able to do any task, in reality, each task is normally done by one dev (or two in a peer programming scenario). If a dev makes the estimate (and breakdown, etc) who will not be working on it, then you lose this very important preparatory step.

  3. Jon Kiparsky says:

    A few amendments that I would suggest:
    – Estimate as a team. Many heads are better than one, you will see snags and opportunities that I will miss and vice versa. This also means that you’re not pre-assigning tickets to individual engineers but instead making a promise as a team, which allows for better flexibility and therefore velocity.
    – Don’t try to estimate hours. Estimates in terms of time-to-deliver are misleading and not useful for planning. Instead, estimate in points (“t-shirt sizes”), and plan based on points delivered in recent sprints
    – be pessimistic in your estimates. Don’t assume things will go well, estimate the worst-case.

  4. Just No. Devs should never have to give accurate estimates. Devs should never have to account for every bit of time they might spend doing housekeeping. Everybody should understand that development time estimates are inherently inaccurate and subject to unknowns.

    What devs should do is give general estimates with advice about what could be changed. Things like:

    “Overall this looks like it could take a week or two to implement”

    “That part is a quick win. We could knock that out in a couple hours.”

    “This part is really awful. That is going to take weeks to implement.”

    “This project looks like it could take months. Here is where it could be divided into smaller releases.”

    1. Yaakov Ellis says:

      Hi Stephen. Thanks for the comment.

      Part of what I was getting at is that the process of making an accurate estimate forces you to think through all of the parts that will go into building what needs to be built. In the article, I do get into ways of breaking things down as part of this process.

      But I am specifically interested in finding the parts that are “really awful” as far in advance as possible, and determining what makes them awful. To say “this is awful and it will take weeks” is avoiding the question of why. Why will it take weeks? What are the parts that make this up? Is the “weeks” estimate just a placeholder for “I don’t actually know what this will take and I would rather postpone that for later”? If so, then the right time to figure that out is “right now”.

      Going through the process of thinking things thoroughly up front, and making sure to understand what needs to be done and how you will do it result in a more accurate estimate as a side benefit – the main benefit is better planning and preparedness for the project, resulting in lower risk, fewer scope changes and surprises, and better quality work.

      1. Jack D. Leach says:

        I don’t necessarily agree. If we’re doing an estimate, that generally means the work isn’t approved yet. It takes a long time to come up with a very accurate estimate, and the right time to figure out the nitty gritty can’t usually be “right now” if we’re just looking for a general scope estimate. We actually charge clients for a discovery phase before we give a full project estimate, simply because the task of generating an accurate full project estimate is in part the same task as designing the project.

  5. I disagree with many of the points. At the very least they should not be considered absolutes despite all the “always” and “never” claims.

    Estimates should not be held up to be holy. They will be wrong. Accept it. Try to get a reasonable level of accuracy, sure, but it is often useful to get a quick and dirty estimate for various options way before nailing down a spec. Because if some alternative takes 10x the time, that should be considered in speccing.

    Having the developer who does the work make the estimate is useful. But there are definitely situations where I trust someone else’s estimate more than my own. If I’ve never touched the codebase before, I’d rather work off of the estimate of someone who has.

    Also, if you update the estimate, the original estimate should still be retained for tracking how well estimates match up. Having the spec change a little is quite normal for anything more complex and some amount of that should often be part of the initial estimate.

    1. Yaakov Ellis says:

      Hi Otus. Thanks for the reply.

      I use the word “always” one time above in a deliberate way: “Always estimate off of a spec”. And I stand by this. Estimating when you don’t know what you are estimating is always a bad idea, in my opinion.

      I used the word “never” in this sentence: Never write code unless you have a good understanding of what functionality is required. And I totally stand by that as well. I cannot think of a situation where it is valid to write code when you don’t understand what it needs to do.

      I am not suggesting that estimates are holy. I am suggesting ways to get them more accurate, and that the process of doing so results in a higher level of preparedness for the project on a whole. And I mention the idea of making high-level, lower confidence estimates. They have their place as well.

      > If I’ve never touched the codebase before, I’d rather work off of the estimate of someone who has.

      If you have never touched the codebase, then I posit that if the estimate is made by someone who has, they will make assumptions in the estimate about the time needed to do things based on their domain knowledge, not yours. It will always take you more time than them if you never touched the code before. And making the good estimate is your opportunity to actually become more familiar with the codebase.

  6. I can’t remember ever accurately estimating a project in 35 years of coding. They keep asking… lol.

    1. I’m in the business as well since 35 years, and the rule regarding such estimates is still true, since those early days:

      If you hear an estimate, multiply it by two
      and take the next bigger time unit.

      1. The Cone of Uncertainty.
        Estimates are that, estimates. In construction there are clauses that state that the estimate will change given certain conditions.
        I see this as educating stakeholders what an estimate entails and why it will change. Coming in “under budget”, i.e. less hours than estimated, ought to be celebrated.
        As a project progresses, the estimates need to be revised. A feedback loop is required to place a value on these changes.

    2. Yaakov Ellis says:

      First time for everything!

      Start tomorrow by just trying to estimate accurately what you will get done in the morning, at a very granular level. The whole rest of the process is expanding the scope of that.

      Of course, for a very large project (hundreds or thousands of hours), there is a diminishing return (and much lower probability of success) in getting things spot on from the beginning. However, the difference between coming within 10-15% on an estimate for a 1000 hour project and being 100% off can make a world of difference for all of the non-dev stakeholders who are part of the project and rely on its outcome.

  7. Appreciate your attention to this critical issue!

    First, of course, the project should be broken down by modules, and those estimated and summed. If you want to get general/team estimates, have different people estimate the project independently, then average those. I would never let myself be bound by someone else’s estimate.

    I am currently working on a project with a guy who is more advanced than me. We both estimated the entire project independently, and those came out pretty close. However, I found that he often tries things five different ways. Notably, my estimates assume that I work efficiently without excessive re-do. Otherwise, you get tired out. Importantly, work styles in collaborations can impact estimates! When projects and estimates become collaborative, plausible deniability increases exponentially! 🙂

    Oh, and I use Excel primarily to estimate, and good points about not estimating incomplete sections and/or providing confidence levels!

    1. Yaakov Ellis says:

      Thanks for your comment Andrew. It looks like we are on agreement about many things related to this process. Best of luck on your project!

  8. I don’t believe in “real” estimates. Too many variables are out of one’s knowledge and reach.

    For example, you might be asked to do something you have already done before so you feel confident. Except, you have to do this in an already existing codebase that you barely know. So they (team lead, business person, etc) ask you every day: “when will you have this finished”. And surprise, everything that’s in there, needs refactoring (if not a complete rewrite).

    But the devs who wrote the code are not there anymore. So in the end you need 10 times more efforts to do the thing you usually do, and the non-technical people think you are stupid ’cause your estimate is well past the original date and everything was working fine so far.

    I don’t believe in accurate estimates on long term, only “small” features where as a dev you have 100% control, over their development can be more or less guessed (joining your point about being granular).

    Further than that is as good as weather forecast. (They usually nail the next day and that’s it.)

    1. Yaakov Ellis says:

      Thanks for the comment Ao.

      For the case of your example, my recommendation per what I wrote above is to preempt the daily questions with some extra preparatory work beforehand. If you barely know the codebase, then you need to spend some time _before_ you start working trying to figure out how you will go about and implement things. Only then can you try to set reasonable expectations. Of course, if you never look at the code or architecture before starting, you will fall behind once you start working on the actual code that needs lots of refactoring. But if you spend the time ahead of time (and the time needs to be spent regardless) to see what the risks are, you can take this into account, give stakeholders more options (we can spend more time refactoring, which will help us out with implementation and long term maintenance at a cost of one more week now, or we can do our best to implement as-is without refactoring, but I am confident it will cost many more times than that in the long run).

      Best of luck.

  9. James Watson says:

    While this article contains a lot of conventional wisdom and some useful advice, it’s a demonstration of the big problem that we have with estimates and software. There’s a general misunderstanding of what an estimate is and how they should be used. This article discusses the ‘accuracy’ of estimates but not once does the term ‘precision’ appear. You came close with the paragraph about providing ranges with confidence levels. In addition claiming that breaking things down into smaller items makes your estimate more accurate is very questionable. It makes the estimates more precise but can be highly detrimental to accuracy. For example, if you measure a football field with a inch-long ruler, your measurement will be much less accurate than if you use an unmarked yardstick. It’s true that error in aggregates of estimates tend to cancel out but only if you’ve not gone beyond achievable precision which is roughly on the scale of days for humans. Not all hours of the day are equivalent: https://www.theladders.com/career-advice/the-time-of-day-has-a-significant-effect-on-your-productivity.

    You state “… it is much harder to give a number that is in any way accurate” This is 100% false! It’s very simple to provide accurate estimates. You simply reduce the precision. If I am asked to guess your location, I could pick a residence. Or I could guess a country; a much less precise guess but more likely to be correct. In order to eliminate almost all chance of being wrong, I’d guess you are within the Earth’s atmosphere. The challenge is finding a precision that is both useful and achievable. I’ve never seen a project that needed an estimate at the precision of hours but that’s almost always what is requested. Week (or multi-week) precision is usually more than adequate for a significant effort.

    The big problem with estimates in software is that almost no one will talk about precision even though it’s inherently part of estimation. Part of the reason may be that many people believe ‘accuracy’ and ‘precision’ are synonyms. The use of “T-shirt sizing” in agile methodologies can be used to deduce the precision of estimates but I don’t get the sense that this is commonly done.

    The person asking for an estimate should be telling you their precision requirements. If they don’t you should ask. A request to estimate how long something will take with 95% confidence is a much different request than the expected time. Both can be useful depending on the context. Most of the conflicts I see around this is when the project manager expects something like an 95% estimate and the developer gives an expected (average) time. The actual time taken on a given deliverable is very likely to be more than the expected estimate, even if that estimate is highly accurate! At the very least there should be a default precision when one is not stated and everyone involved needs to understand what that is and what it means.

  10. When real customers are ready to pay real dollars, they expect the timeline to be real. Therefore, I completely agree with Yaakov that developers _MUST_ provide estimates. That said, following points should be noted:

    – Think atomic. A bright engineer already has a good handle on how long (therefore, dollars) an ‘average’ API (verb + resource) may take. If not, think files, functions, etc. (You will quickly see that, this approach automatically enforces a design discipline also.) The caveat here is, often estimates are not linear.
    – Automate. The first attempt at any problem should serve as a launchpad to build artefacts that can help reduce time for later work. Not only does it make one competitive, it also frees up time for more imaginative work.
    – Product or Service. Often product development is exploratory and services are ‘mechanized’. So, if a customer is looking for a brand new UI across devices of different form factors, users across the world, then a good deal of time is ‘co-development’ where the customer _MUST_ commit their resources to come to a conclusion. Services, on the other hand, mostly require execution of ‘known’ procedures. (Think of this point as a request to design a new carburetor versus maintaining one.)
    – Work backwards. Anytime a customer or management makes demands, ask for _their_ timeline (1 week counting weekends or 1 month considering 8 hours per workday) and _their_ budget ($1000 or $ 1 million). Then, countdown to today and show what is possible. (The salesman who won the deal for you should have guts to deny working on weekends and shoe-string budgets.)

  11. I’ve been at this a very long time, mostly working on business applications, rather than (comparatively limited, well defined products like SO) but I don’t remember ever working for a customer who knew what they wanted well enough to be able to give a developer enough information to estimate a product or feature in hours.

    Estimates are for giving managers (and accountants) something to manage. I’ve found that instead of judging what you want to do by its estimated development cost, you should decide how fast you want to afford to spend your money and just focus on building the highest value features that haven’t been built yet. When you run out of things that you feel are worth spending money on, you’re product is finished.

    The only “must” I put on estimates, when I’m stuck working with them, is that anyone who gives me an estimate with more than one significant digit of precision must be lying to me (and probably themselves).

  12. Just do Monte Carlo simulations instead of wasting developer time on estimation games.

  13. From a business perspective (and especially if you are contracting the dev work in); you need a dollar figure and a range of confidence to be able to make a decision as to if the value is worth the cost (and also to gauge whether you can afford the overrun!)
    How do you get a dollar figure? You need an estimate in a way that translates to dollars.

    From a developer perspective, estimates are unholy because developing is still an art, not a science and it relies on a dev to take a spec and turn it into a working product which is implicitly built on many many assumptions, even for a small piece of code with an apparently complete spec.

    Both sides are ‘right’ and there’s no one ‘right’ way to do estimating but I do like most of the points above.

    For those making the point about points (punny!), if you’re an internal team vs contracting, that makes lots of sense. If you’re a contractor team on a short/medium job, it makes little to no sense.

    Re the ‘team needs to make the estimates’ – if you’ve got a team that’s been together for a reasonable time; that’s valid. If you don’t then I think you really should have the developer doing the work do the estimate.

  14. Joshua Jacobson says:

    https://www.youtube.com/watch?v=QVBlnCTu9Ms
    Summary: communicate predictions rather than estimates based on a lot of planning

  15. This:

    “Never write code unless you have a good understanding of what functionality is required”

    The Number ONE Gold Rule #1…It cant be mentioned enough…

    1. Paul Williams says:

      “Never write code unless you have a good understanding of what functionality is required”

      Good idea, but assumes the rug won’t be pulled out from under you when the functional requirements change, thus invalidating the weeks’ worth of analysis you did.

      1. Yaakov Ellis says:

        Yeah, that is always a risk. But being as prepared as possible for the eventuality that functional requirements will not change in a major way is a good thing to have for every time that they don’t change. Whereas never preparing and trying to understand the functionality is a bad idea 100% of the time (in my opinion).

  16. JoshLikesBeer says:

    Complete functional requirements are necessary but not sufficient to give accurate estimates.

    If I’m working on a task that’s similar enough to things I have done before, it’s not hard to give a reasonably accurate estimate.

    If I’m working on something that requires research and experimentation and reading CompSci PhD theses on arXiv to discover how to implement, then it’s impossible to give a useful estimate. Might be a week if I’m lucky, might be six months, might be never.

    1. Yaakov Ellis says:

      Thanks for the comment Josh.

      In the second case that you present, I would posit that you should not be writing your estimate until you complete your research and experimentation. That is part of what you need to do to understand what it is you need to build and how you need to build it (prerequisites for breaking it down and estimating).

      Now, sometimes you might have a discovery project where you need to estimate how long the estimation phase will take (recursive estimates are always fun)…

  17. Jerry R. Jackson says:

    It’s a good thing that accurate estimates are _not_ needed to produce good software since they fundamentally don’t exist.

    1. Yaakov Ellis says:

      Thanks for the comment Jerry. I guess we’ll just have to agree to disagree.

  18. Mark Derail says:

    I liked this article so much, I shared it on LinkedIn.

  19. Many of these points tie in with my own experience, I agree with the breaking of work down into small deliverable and testable tasks are always helpful. 6.5 hours of productive project work a day seems a little high though, by the time folks have done emails, discussed weekends, had a few interruptions, I think you can knock another hour off that number. If you are a contractor working on site, you can sometimes spend a lot of time explaining progress to the client, mentoring others and participating in weekly meetings.

    Pushing the idea of project estimates slightly to the side, we should factor in some business technical analysis as a project cycle in its own right; it is the output of such work that removes some of the design unknowns that in part handicap any technical development work load estimates.

    One other point, green field development requires a certain amount of development and technical test and acceptance test infrastructure, in order to bring some orderly progression to the design and development life cycle. Without this pre project investment it is difficult to keep on top of, and juggle the differing needs of stakeholders who can change their mind on what they want, technical support, further development and product maintenance.

    In addition, committing stakeholder to some of the delivery work in order to validate their conditions of satisfaction does add some intangible time to delivery estimates. This is especially true when business analysis has not been completed, as acceptance testing is often the time that final ideas for business needs are fermented and solidified.

  20. A wise person once said “First rule of software engineering: absolutely never believe rules that state to always or never do something” Which I believe you should always do.

  21. Kristada673 says:

    What can I do when asked for estimating the time I will need for something I have never done and have no idea how it works? A very real example – I was recently asked to finish a Tableau dashboard that was around 90% built by an external vendor, to complete the few tasks that were too complex for him in the limited time-frame he was given. I am a dev who has never worked with Tableau for more than a combined total of probably 5 hours before this assignment.

    I struggled for 2 weeks; I couldn’t finish the thing. I was asked to estimate how much more time I would take by my boss. I informally went and told the senior guy in our team that I can’t estimate this, I have no idea how much time it will take. I wanted to suggest that it would be much, much better to just pay the vendor for 1 more day and get it done; taking on others’ half done work is anyway I’m not too comfortable with, even on things I am familiar with. But the senior guy said, the vendor did the whole thing in a week, only a little bit is left, it can’t be too difficult; if you find issues, just try to find workarounds.

    So, under pressure, I replied to boss saying it would take 4 days. When I very well knew that for a Tableau expert, who knows what the root cause of the issues is and how to fix it, it can’t take more than a couple hours at max. But of course I couldn’t finish it in the next 4 days as well. The senior guy kinda scolded me, the whole thing is very embarrassing and degrading to me, and I feel like shit now.

    1. You cannot do anything and your initial approach was the correct one. Stating that you do not know enough to provide estimate and you have no idea how long does it take.

      Also one of the most evil thing that exists is “I have dev-ready project, just take it and finish it, its almost done”. This is never ever true, sometimes it can be even worse than creating it from the beginning by yourself, especially if it lacks proper documentation and/or quality of code. Its pretty easy to write some code that “should work”, but I do not consider it completed unless it is deployed, tested and it works as expected.

      You got however valuable experience, that you should not estimate “under pressure” or to make “someone happy”. Even if it is discomforting at the moment, you have to stay for your initial opinion/estimate like “I dont have enough information about this technology and project, it can take weeks, but I cannot promise anything”.

  22. That is very good article, thanks!
    It nicely summarizes the estimation part, best practices and how to handle general situation.

    I can see a lot of comments here with criticism, but for me it mostly looks that it is caused by ignorance. One big part of criticism is as “Me or my team were never able to provide good estimates, therefore improving the way how to do estimates is nonsense”… Second part is usually “but you did not mention X,Y,Z or the different part of software lifecycle” – well yeah, unless you dont want to write a book, but just one article, you cannot write about every single aspect of software development.

  23. Aaron M Eshbach says:

    Have you tracked the accuracy of your up-front hour estimates throughout the lifecycle of your projects? What level accuracy do you tend to find for non-trivial efforts? In my experience, up-front hour estimates are rarely as accurate in terms of planning when a project will be completed as using Velocity based on historical sprints.

  24. It is impossible to overemphasise how important it is to start with a complete spec (ie: perfect knowledge of the problem domain) in order to produce meaningful estimates.

    When the client asks for features that you’ve never done before, how do you estimate that?

    “I want an iPhone app which will record the geographic location of each photo, and then identify all the birds in the scene.”

    Well, one of those is easily estimatable and the other is really hard to estimate because it involves bleeding edge technology.

    And then you get to jobs like, “interface between our system and this vendor’s API” but the vendor hasn’t fully specified their API and the data you receive doesn’t conform to the specification provided — extra fields have been added, some fields aren’t used anymore, you don’t get meaningful error messages when your inputs don’t conform, the documentation is about two or three revisions behind the actual API and the changes are only notified to the favoured users over beers at the pub.

    Estimating stuff you’ve done before is easy. Estimating stuff that hasn’t been done before is hard.

    So for me, step 1 of estimation is “be omniscient.” Good luck!

  25. Uncle Bob says: always multiply your initial estimate by three.

  26. Brian Maissy says:

    I personally find that “days” are a useful unit of measurement in which to estimate my own work. I feel that I have a stronger intuitive feeling for what I can accomplish in a day than in an hour.

    I can estimate in days in a couple minutes, rather than spending a couple hours breaking the task down enough to estimate in hours.

    As in the case of measuring “a football field with a inch-long ruler” that James Watson mentioned above, the attempt to estimate with higher precision can sometimes cause lower accuracy because of aggregated rounding errors.

    Also worth noting is that estimation style and technique should be adapted to the type of task at hand. Estimating a relatively straightforward implementation of new functionality within a stable framework should be held to a higher expectation of both precision and accuracy than a more open-ended R&D type task, large refactors, optimization tasks, etc.

  27. Ah! Such a great piece of writing Yaakov. We, being a software provider couldn’t agree more. Proper estimation opens many doors for the developers – they know what to prioritize, they can dedicate resources according to the time estimate and if they are multi-tasking, they know where to spend their time and how much. Looking forward to read more articles from you!!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.