Is the ability to estimate hours an essential quality of a programmer?

Question

Is it possible to be a great programmer without being great at estimating time for a given task? Can you be great at one and not great at the other and still be 'successful'?

Answer 1

No, it does make you a terrible project manager though ;)

More seriously though, I don't think I know a single programmer who can without a shadow of a doubt tell you exactly how long, down to the hour, something is going to take. The problem, I find at least, is that we are generally a population of "this should take x amount of time" and people requiring the time line hear "this will take me x / 2 amount of time".

Keep the rule of however long you think it will take, multiply it by 3-5 (but don't be ridiculous), and try to take testing and debugging into consideration too. Another crucial aspect is that people don't break up tasks enough. Make sure every piece of work is a manageable and time-able solution. Saying it will take you 20 hours to do the accounting system means squat.

Answer 2

It may make you a terrible employee, but not a bad programmer. ;) If you hate to do it, chances are you aren't able to estimate very well is my guess. Perhaps set some small goals within your project. Estimate (to yourself, of course) how long you think that task will take to complete. See how close you get. Do it A LOT. You'll get the hang of it. Also, I always always double my estimate. If it takes me a day, I say two. :D

Answer 3

Well, software estimates involve breaking down the problem into parts which can be estimated. It also involves being able to analyze those small parts and use your experience to estimate how long it will take.

You also have to look for the assumptions and analyze the best and worst cases.

The above all seems to be something that a good programmer can do; you may just need some training. Check out the book "Software Estimation: Demystifying the Black Art" by Steve McConnell. It will probably improve your abilities in this area.

Answer 4

Hating estimating does not make you a bad programmer, but an ability to accurately estimate the time it takes to write code is one of the skills of a good programmer.

Unfortunately, the only way to get better at estimating is practice. There are plenty of books and sites that go into the art of estimating (and it is an art), but in short, you should:

• Decompose your task to as fine a granularity you can
• Estimate the time for each subtask
• Add up those estimates to give you a total time
• Track the time taken on each subtask
• Figure out why you were wrong
• Repeat until you start estimating correctly

Mistakes to avoid

• Worrying over the accuracy; an estimate is just that, so don't estimate in finer increments of, say, 5 minutes
• Worrying over correctness; as you're practicing, expect to be wrong... even dramatically so. The benefit is in figuring out why you were wrong
• Worrying over concreteness; you're allowed to change your estimates as you get into your task or as the task changes. Indeed, as you get better at estimating, you will get better at informing your project manager as to the time cost or requested changes

Answer 5

Start by determining why you hate estimating the time it will take:

• Are you too optimistic in your estimates and fail to realize them?
• Do you feel extra pressure by stating a deadline?
• Do you have enough time to complete your projects or do they ask you for impossible deadlines?

Be sure to plan to plan optimistic, because developers simply think that everything takes two weeks ;) to finish. At my office we have this Pi-rule, where most of our estimates are multiplied by 3.14. Meetings, issues, bugs, there are quite some things that will always steal a bit of your time as you go.

You aren't a bad programmer if you're a bad planner, but in the real world people just like to know when your work is finished so that they can tell their boss, the customer or any other stakeholder in your project :)

You might find this a useful and entertaining read: Evidence Based Scheduling

Answer 6

Listen to the stackoverflow podcast and you'll hear Joel chastize Jeff about "6-8 weeks" which is what Jeff constantly says it will take to do whatever project.

This stuff is hard to estimate. Programming is not putting a hammer to a nail. You can blow through some really hard stuf, then get stuck on some small trivial problem for hours.

So it doesn't make you a bad programer. It makes you bad at estimating how long something will take.

Answer 7

Estimating is kinda subjective. Specially because you rarely get all the information you need to estimate accurately. Even if stakeholders try to provide you all this information, they can't, because they don't have it! They will realize what they really need as you start delivering the software.

Answer 8

Estimating is an essential quality of a programmer. The business needs to know when something will be complete and how much it will cost in order to determine if it makes business sense and to continue funding the project.

The thing with estimating is that the larger the task, the more likely it is to be wrong. I've also found the opposite is true - the smaller the task the more likely it is to be right. Use this to your advantage...

Start by decomposing large tasks into smaller and smaller components until no task is longer than something you feel you can estimate correctly - let's say 4-8 hours.

I've also found it helpful to then prioritize these tasks using the following criteria:

• place dependent tasks lower in the list
• place well defined tasks higher in the list
• place the highest priority tasks (from a business perspective) higher in the list

At this point you've essentially transformed your estimate into a schedule.

Break this work into weekly or bi-weekly iterations and plan on delivering at the end of each one. By doing so, you know at any point in time if you are ahead of or behind schedule. It's pretty simple in practice and has worked for me.

Answer 9

Estimating isn't essential for a programmer....but it is essential for a programmer who wants to move up :-). Estimating, documentation, etc. are honestly pains-in-the-butt for those of us who love to code - but in teams the guy who does this kinda stuff is seen by managers and such as the guy who coordinates the project.

Here's the way I've done it typically:

1. Count the number of screen changes and assign each a low,medium,or high complexity.
2. Do the same thing for interfaces, business logic, database changes, design documents, testing, etc.
3. For each of these items decide how long it would take to do just that thing (how long to do a low complexity screen change for example).
4. Plug the estimated hours into the equation and come up with a subtotal of what you think.
5. Add a 'fudge percent' to the equation for things that come up (I usually do 1/3 of the total).

There is my usual estimate. Hope that helps.

Answer 10

Does that make me a bad programmer?

It depends: do you want to get paid for programming? Because if other people are paying for you to develop code the chances are they need to know when they are likely to get it. Similar considerations apply in non-commercial environments too. But it's more pressing in commercial situations, because there's money involved and people tend to get anxious when there's money involved.

To a large extent making a career out of programming is about becoming extremely efficient at handling the stuff we hate (estimating, documentation, progress meetings) in order to maximise the time available for doing the stuff we enjoy (cutting code, er, that's it). Of course, "handling" can mean "avoiding altogether" but achieving that actually requires a lot of political skill.

Answer 11

Does poor Software Estimation make you a bad programmer? That depends on why your estimates are so wrong. Part of being a good programmer (in my view) is being able to see the solution fully before you begin, and put the pieces together to get you there.

There are absolutely times when your original solution has issues, and you have to adjust and refactor, but that's what makes an estimate... an estimate... in other words, it has inaccuracy cooked right in.

There are many ways to become a better estimator though. I would highly recommend the book, "Software Estimation: Demystifying the Black Art" by Steve McConnell. There are lots of methods and ideas on how to become a better estimator (for all types of people, project managers as well as developers), as well as good evidence about the importance of estimation.

Answer 12

I guess it's obvious that most programmers underestimate time efforts. I think it starts with the belief that "it can't possibly take that long". It seems embarrassing. But you have to include the complete life cycle of the work being done (feasibility, functional spec, tech spec, design, coding, testing, integration, packaging, delivery, documentation, tech support and maybe even marketing).

Here's a formula I made up for handling programmer's estimates: E' = E * (1 + 2/ln(n)) where E is the original programmer estimate, and n is the number of years of experience (n > ~1.3). ln = base e logarithm.

Answer 13

I believe estimation accuracy comes with experience. You can be a good programmer who gives bad estimates, but an experienced programmer will normally be no more than 20% off.

• Do some technical planning before you give out an estimate. Managers love asking for estimates on the spot, but this is not reasonable ... you have to get a high-level idea of what's involved first.
• Break a project down into smaller phases or iterations if you can. The less novelty there is, the easier it is to estimate.
• Add extra padding to your estimate for each unknown factor.

Hating estimates doesn't make you a bad programmer. By giving out an estimate, you're basically putting yourself under self-inflicted pressure from your own deadline. What's there to love about that?

Answer 14

Estimating schedules is hard!

Yes, there are ways to make it easier, but despite fancy tools like evidence based scheduling generally I think very few programmers can be considered to actually be good at estimating schedules.

IMO Being bad at estimating doesn't mean you are any worse as a programmer, however being getting better at estimating schedules will make you more useful as a developer. (i.e. the software you produce is probably going to be just as good, it will just be late, or if you are lucky - early)

It is also definitely a skill that requires experience - I am rubbish at estimating how long things will take, but I'm finding I am getting better at producing in-the-right-ballpark estimates as time goes on.

In the meantime I take solace in the fact that what I produce generally tends to be very high in quality, even it doesn't turn up when you expect it! And generally that isn't too much of a big deal anyway - it's unlikely it would have been done significantly quicker if you had accurately estimated how long you would spend.

Answer 15

A good estimate has little to do with programming skills and everything to do with the quality of a good spec or requirement document. Essentially, a good estimate is one that results in happy relationship, while a bad one results in an unhappy relationship with your client. Without one, the project is doomed before it even begins. Beware of the software methodology folks who say you don't need a written spec or requirements. Most reasonable clients want to know how long and how much it's going to cost--they are leery of entering into any engagement that is open-ended and unclear. Frankly, they need to know what to tell their bosses and they don't have an unlimited amount of money and time.

The clearer the document, the better the estimate. Write this in a way that can be easily understood by you and the client. Make sure you include screen mockups, charts and graphics. Client's don't want technical verbiage, they want pictures. Break these up into logical units and assign a time and cost to it. If you are unsure about any part of the specification, clarify it with the client. Don't assign a number if you're not reasonably certain. Total all the units and use a multiplier of 2 and you're done. It's that simple!

Unfortunately, neither the programmer nor the client wants to go through this process. The client sees this as a useless, time consuming exercise, and on the other side, the programmer just wants to write code. Without one, however, you'll be in for a shocker when you find that the software expectations aren't aligned. The programmer may be thinking of writing BMW quality software and often the client is expecting Yugo quality software or vice-versa. Consequently, the client either may balk at the programmer's estimate or become disappointed later after expecting a BMW and getting a Yugo instead. If it gets really nasty, neither of you have anything to stand on in court.

Hold the client's hands and walk them through the process of writing the specs and bill them throughout this phase. As a selling point, tell them if they don't like the estimate that will result from it, they can use it to shop estimates from other developers. If the client refuses, walk away and fast! If they are not willing to pay for this activity, it's a sign that they don't value your expertise and that the experience will be bad.