An answer to an estimate question.
If you are in a creative industry, chances are high that you have been in a situation where you were asked to give an estimation of what you are going to do or what you are currently doing. Questions like; How many months will it take to deliver your project? How much disk space will you need for a billion items? How long will it take you to deliver task x?
At one level, these are all meaningless questions — they are all missing information. And yet they can all be answered, as long as you are comfortable estimating.
One may ask, what could be the appropriate answer when asked such questions? Well, before we get to answer this question, let us first get to know what estimation is.
There are a couple of different definitions of estimation specifically related to software development but I will go with the Wikipedia version.
Estimation is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available. — Wikipedia
It is a ton of words but I love the last part. “The value is nonetheless usable because it is derived from the best information available.” By learning to estimate, and by developing this skill to the point where you have an intuitive feel for the magnitudes of things, you will be able to show an apparent magical ability to determine their feasibility. When someone tells you something, you’ll be able to know intuitively whether it is practical. When you’re coding, you’ll be able to know which subsystems need optimizing and which ones can be left alone.
Most of us when asked about estimation, an awkward silence may be created, we get nervous, tend to freeze while processing the answer and our responses begin with a couple of hmmms while looking up and alas, the temptation comes and you start saying “it could take me…”. In most cases, the manager or whoever is asking may be interested in a specific answer. So you may be tricked into promising a specific time with less knowledge and thought about the problem. You end up providing an answer without certainty.
Robert C Martin commonly known as uncle Bob in the programmer’s oath, item 8, advises us that we should make promises with certainty. Item 8 states that:
I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
The most honest estimate is “I don’t know” but it is also the most useless estimate one can make. I guess no one wants to be given that answer. The Golden Rule states that treat others as you want to be treated. So don’t give that answer if you won’t accept it.
“I don’t know” is the most honest answer but how do we make it useful? Well, we need to come up with a useful and honest estimate — a significant estimate that expresses our “I don’t know” in a better way. How do I do that? You may ask.
Before we continue, let us first answer whoever asked the question about estimation in a non-blocking way and release the fellow. The best asynchronous answer from the pragmatic programmers is, I’ll get back to you.
After releasing a fellow, let us get to work so that we provide something useful in the end.
There are many ways to come up with estimates that are honest and useful. I’ll highlight a few of my thoughts below.
A basic estimating trick that always gives good answers is;
Ask someone who’s already done it.
Get someone who has been in a similar situation in the past. See how their problem got solved. You may not find the exact match but it is a great starting point based on someone else’s experience.
Here are some steps you can take to help you provide a better estimate.
Understand the problem. Understanding what is being asked is key. You need to know the scope of the domain, the accuracy required and any information that may be useful to improve your understanding of the problem.
Build a model. From your understanding of the question being asked, build a rough skeletal mental model. The process of building the model often leads to discoveries of underlying patterns and processes that weren’t apparent on the surface. Other variants may come up. You could have been asked for an estimate of Z however Y, a variant of Z could manifest.
Break the model into components. Handling a problem as a whole is a complex process. One of the ways to handle this complexity is using the divide and conquer technique. Identify those small components that contribute to the overall model. Break a component further if it is still complex and get to know when to stop.
Give each component a value. You can go through each component and assign it an estimate depending on its complexity. You can provide an estimate using a three-point rule by considering the best case, an average, and a worst-case scenario. You’ll also often find yourself basing an estimate on other sub-estimates.
Compute the overall complexity. Calculate the complexity of the model. When computing the overall complexity, you may get strange answers(for example two days for the best case and a month for the worst-case scenario). Don’t be too quick to dismiss them. This is valuable information.
How accurate should the estimates be? You may ask. To some extent, all answers are estimates. It’s just that some are more accurate than others. What is important here is the context in which your answer will be taken. A kid trapped in a burning house is interested in an answer down to a second, compared to a friend calling to ask whether you will be available in the evening so that he can buy a movie ticket for you. In software, a project to be used in the world cup coming up in the next 3 months won’t accept an estimate of 5 months.
Keep track of your estimates. It is a great idea to record your estimates so you can see how close you were. When an estimate turns out wrong, don’t trash it and walk away. Find out why it differed from your guess. Take some time to uncover what happened. If you do, your next estimate will be better.
Communicate the estimates. With the overall complexity at hand, we can provide our answer to our fellow whom we released earlier with certainty on how long it will take us when everything goes on well, when things go really wrong, and an average. That way everyone understands the shape of your uncertainty(your “I don’t know” now is useful).
When communicating your estimates, the units you use make a big difference in the interpretation of your result. When you use “130 working days”, it will be expected to come in pretty close. When you use “about six months”, people will know to look for it any time between five to seven months from now yet both numbers represent the same duration. Authors of the pragmatic programmer book advise us to use the following scale.
Some managers are interested in exact dates so what should we answer when they ask for an exact date. Let me share the answer that I learned from one of the elders I respect in the industry. He is uncle Bob, the one quoted earlier and here is the answer:
- Never give a date.
You give a date, you are lying. When asked something like “can’t you give a date”. The answer is “No I don’t know the date”. Can you get done by Friday? The answer is “I don’t know if I can get it done by Friday”. They may become manipulative with something like “well will you at least try…”. The answer to that is NO. The “try” statement is its self insulting, I mean you are already trying, already giving your best(That is if you are truly giving your best).
In conclusion, let me hope this information helps someone and lastly, I will end with Jim Rohn’s statement: “Be a student, not a follower”.
