Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was presented with a new problem recently, to provide an estimate for a project in which I must use a framework (and potentially bits of another framework) that I am unfamiliar with. It's much easier for me to provide estimates when I'm at liberty to use what I'm familiar with, but it was as though a crippling paralysis by analysis had kicked in when an estimate was requested for work in unfamiliar territory.

My solution, in retrospect, was wrong. I merely began working.

How might I better estimate projects and tasks when I am required to work with unfamiliar languages/technologies/frameworks?

share|improve this question
Giving an estimate on something you have never done is, in all practicality, impossible to do with any precision. I recently gave this analogy when asked how long something would take when there were a lot of unknowns: "Imagine you are walking out in the countryside at night. It is pitch black. You need to walk one mile overland. You know which direction you need to go, but you only have a lantern that illuminates ten feet. You have no idea what lies ahead of you: field, river, mountain. Given this, you can make educated guesses, but ultimately you are subject to things outside your control" – Nemi Jun 15 '11 at 21:45
This also depends on the purpose of the estimate. Are you estimating for most likely case? Worst case? Are there hard deadlines involved? – David Thornley Jun 15 '11 at 21:47
@David I believe this would be a "most likely" case. – Sampson Jun 15 '11 at 22:25
up vote 18 down vote accepted

The standard answer from the agile textbook is to perform a spike. A spike is a time-boxed task to explore the unknown, so that at the end you have (hopefully) sufficient information to provide a useful estimate or you have a better idea of how much more time you'll need to get to that point.

Spikes can last anywhere from 1 hour to several days or even longer. Since they are time-boxed, there is no risk involved for either party, and the expenditure is strictly limited.

Ideally during the spike you would identify a few simple things that needed to be achieved with this new framework and set about very simplistic solutions using it. As you go along, you learn, and that's what spikes are all about.

share|improve this answer
Maybe it's a good idea to add that "spike" is terminology from Scrum. – Jesper Jun 15 '11 at 13:50
Sounds like a good approach. In my particular case, my "spike" consisted of the project itself. It seemed a valuable use of my time to actually use the task as my gateway to familiarity rather than some unrelated task. – Sampson Jun 15 '11 at 15:27

The classic way of doing this is by refinement. At the first planning meeting you say;

"I have no idea - we are basically doing software research here. However, I will have a better estimate by the next meeting, in a months time"

Then you go away and do the research. Next meeting:

"It looks like it will take anything from two to 4 quarters. We are going to build a prototype which will let us refine figures further".

Next meeting:

"The prototype was easier to build than we thought. It looks like we can do it in 2 quarters, plus or minus a month."

and so on. At each stage, the business has the option of canning the project, or letting it continue, getting better and better estimates of the completion date as it does.

This is described very well in Steve McConnell's great book Rapid Development, which deserves to be far better known. Certainly it is far superior to any of the books on "agile" I have read.

share|improve this answer
+1 Thank you for the insight, @Neil. I'll look into the book suggestion as well. – Sampson Jun 15 '11 at 15:28

You can do research and still come up with wrong estimates. See Large Limits to Software Estimation by J. P. Lewis, and the accompanying material Mathematical Limits to Software Estimation. I'm not saying that you shouldn't bother to estimate or to research, just that you can't make an objectively accurate estimate, and you need to say this along with whatever estimate you arrive at.

share|improve this answer
Estimates are by definition inaccurate, and it seems that many managers and/or customers struggle with this reality. – wolfgangsz Jun 15 '11 at 14:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.