Junior Programmer – Dealing with Estimates

Long reply, but hey, I’ve got a summary on the end, so just skip to summary if you can’t be bothered reading the entire thing!

As a developer I had to deal with the situation literally every other project, but it's not until I moved into project management that I learned how to deal with it effectively. For me dealing effectively is about two things: managing expectations and understanding how estimation works.

Start with a premise that it is unethical to provide an estimate, commit to an estimate or give any other indication of estimate accuracy without being able to carry some due diligence first. Other people rely on your professional ability to predict an amount of work required, giving a false indication will hurt them and their business.

But you have to give something, in real life you dragged into an impromptu meeting or a late project and your superior will probably make it clear they expect you to come up with some figure straight away or comment on the estimate they provided. This is where expectations management comes into play.

Explain that it would be wrong of you to give any figure or any indication without understanding the problem and working the numbers out for yourself. Say that their figures might be quite correct, you just don’t know before you went through the estimation exercise yourself. And even though you might have a good picture of what is needed there and when, say that you still need some time to work the numbers out. There is only one estimate they might expect you to give: when you going to be able to provide an estimate. By all means do provide that figure.

As a developer never take responsibility for (or give indication that can be interpreted as acceptance of) other people estimates without being able to review them first. As a project manager it is a totally different matter, because then you actually have some control over the estimation process: the way an estimate is derived and reviewed and you have to rely on other people to get the actual work done and you need to make sure they are committed.

Never even comment on estimates without being able to do the due diligence. This is ethical. A lawyer or a doctor will make it absolutely clear they cannot give any advice unless a client (or patient) plays by their rules and goes through an assessment procedure first. You similarly have a right to satisfy your questions before giving professional opinion.

The second part is about how estimation works. I suggest researching various approaches to doing estimates and how estimation process works, including industries other than software development (manufacturing, financial markets, construction). This will give you idea what can be reasonably expected from you by your boss or client and, strangely, will help making more accurate predictions about the amount of work. It will improve your ability to defend your estimates and you will need to defend the figures every time they are different from the ones provided by an architect or a sales person.

Normally, the way it works, is that your estimate is first scanned for odd looking or relatively large items. Hence be prepared to defend anything with “non-standard” name. Also split larger tasks so that all tasks have same order of magnitude, i.e. if most tasks take 2 days and one single task is 10 days be prepared to get drilled.

Be clear about what is included in each task, its best to split dev and unit testing instead of just having dev and having someone assume that it includes documentation as well. Obviously this way you’ll need to produce a fairly fine grained estimate.

Next the drilling comes. Since it is quite difficult to review a long work breakdown your client or boss is likely to adopt a different strategy: concentrate on a random bit they might know something about and drill down until they manage to discredit the entire estimate or will be satisfied with your answers. The credibility of entire estimate might depend on a random sample! Hence once again, you need time to prepare it carefully, include only relevant bits, exclude any extras or move them to a “nice to haves” section and think through how you going to defend the figures.

Obviously you can be either consistent in your approach, i.e. estimating on the basis of features, number of screens etc or have a mix of approaches, but in any case be prepared to defend why you selected a certain way of estimation. Be also prepared to explain why your figures are different from whoever else’s attempt at predicting the amount of work required.

Learn the obvious signs of weak estimates:

• Filled with general run-of-the-mill tasks, copied from template (good estimates are specific to the task at hand).

• Coarse grained estimates (i.e. tasks longer than couple of days).

• Estimates done on early stage of a project or by someone who might not have actual knowledge of the requirements or work involved.

• Estimates compiled by people other than actual doers

• Vague estimates (not clear what is included and, equally important, excluded).

• Substantial difference in the order of task magnitudes.

Practise in evaluating other people estimates and drilling the figures without actual knowledge of implementation detail. This will help to back your claim for some extra time when pressed with the request to confirm someone else’s estimate when you have no hard evidence.

To summarise:

• Do not commit to an awful or any estimate for that matter, before you had an opportunity to do due diligence.

• Make it clear on the outset, don’t let anyone assume it is any other way and interpret your silence as a sign of agreement.

• Know how various estimation methods work, their practical application and merits, including these outside software development.

• Be prepared to defend your estimate.

• Learn how to evaluate other people estimates so you don’t have to commit yourself to vastly inaccurate figures.

This is almost impossible to get an accurate cost on. Outsourcing makes this even more difficult.

Just because it's fairly standard doesn't make the task of quoting any easier. For example: you mentioned there is an Administration Interface. This can be as simple as a login and password for each user or complex with users who have multiple roles and a superuser that can oversee all admin tasks. If this becomes a role based admin then the coding time has just increased exponentially.

If you are outsourcing to a foreign country I'd pad the total time and cost by 20% to account for interpretation of questions and answers between customer and coder.

As a ballpark for database driven admins we would estimate 4 hours for each base table. This allowed for table creation, insert routines, update routines, delete routines and the associated admin web pages. This also included a simple listing display page and a detail display page. If search filter queries were required then we'd add 2 more hours for that table.

We did have a lot of code we could borrow from. We also wrote some utility stored procs that helped us speed up the coding by spitting out source code. It wasn't perfect code but it saved us many hours of raw coding. We also would undercut the price if this was a widget we could turn around and resell to other clients. It doesn't sound like you can resell this to anyone else so the price they pay should be a premium.

Is there a similar Commercial Off The Shelf (COTS) system already built that you can buy? Have you even entertained the Build or Buy question?

Custom software is expensive. As long as you make the customer aware of this fact up front and they still want a custom solution, they will pay the premium price. Every time you say, "Oh yeah, we can do that" and don't say it will cost more, the customer will expect it for free.