Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
We all have it, problems that prove difficult to fix and working out a fix through obscure code and bizarre unexpected functionality. Slowly, logically working your way through trying to find patterns, errors, mistakes. This process takes time and the issues are often not easily understood by the client.
How does one answer when asked the question "When will it be done?", especially when the client may not understand the inherent complexities of software development?
You answer the question honestly.
You tell them it's a difficult problem, the solution is not obvious, and you are not sure how long it will take to resolve. Promise to update them on your progress every [time frame], so they know you're working on it, and of course, actually send them the updates.
Developers approach a complex problem by decomposing it into smaller ones and solving them separately.
In an ideal world, solving an issue would be a complex problem A and you would be able, in a given time, to decompose it into a short list of small problems A1 to An, for each evaluating the time is straightforward, given that the time required to solve the initial complex problem would be:
with D being the process of decomposition itself.
In real world, the only problem is that t (D ) would actually be bigger than the time you spend resolving the small problems. In other words, in order to get to this level of decomposition of the problem, you practically need to solve the problem itself.
You can still:
Separate the given task (solving the issue) into smaller chunks, each chunk being still a complex problem,
Evaluate the expected time for each chunk and the corresponding risk.
For example, the task 1 requires approx. 5 hours, but the risk to being blocked doing it is high, so give 12 hours as your expectation to the customer.
Evaluate the dependencies and how they affect the time.
For example, the task 19 requires 2 hours, and the risk is so low that you can say it's 2 hours for sure. Not 1. Not 3. But task 19 relies on task 24: the task 24 may affect the task 19 in a way that you would require to completely rewrite the code of the task 19 using a different approach.
Give all those details to your customer. Don't give the sum.
The last point is important. If you give the sum, let's say 192 hours, the customer believes that it's a very precise metric, and the time you will spend is from, say, 189 to 195 hours.
If, instead, you give the details,
The customer who cares will understand that it's not 192 hours. It's 192 hours if everything goes wrong given the risk determined during the assessment. It's also 238 hours if everything goes even worse. It's also 85 hours if everything is ok.
As for the customer who doesn't care, he will not read your answer in all cases. All he want is a number, to be able to blame you later. By giving a very detailed answer he will never read, you know that he can't ask you for the time it will take again: you already answered that. He also can't blame you later, since he didn't read the answer in order to calculate the sum.
Whatever you estimate don't forget to include Hofstadter's law: It always takes longer than you expect, even when you take into account Hofstadter’s law.
Typically I use a modified formula from CPM/PERT. It's something like this:
Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.
(I'm not sure how to do all the fancy math formatting; if someone wants to edit this for that, then feel free.)
So, if you think:
Mn = 60 hours
Mx = 180 hours
T = 100 hours
C = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.
I'd emphasize that it could vary significantly, depending on how the project goes. If you reevaluate your project every few days, you could even supply a weekly update. It goes a long way towards satisfying irritable clients. :)
Explaining vague timelines to non technical users is tough. This is true both in creative phases of a project, and when tracking down a pesky bug. In both cases the traditional "decompose the work to smaller pieces" doesn't work as well.
The original task focuses on the latter case so let's dwell on that. If you can't give a timeline, tell the user what you will try and when you will get back to them. When you reach the halfway point on the self imposed timeline give a short and honest email update. At least an hour before the deadline give your formal response. Now you have credibility. If the problem isn't solved at least you are shining some light. It may seem like a waste of time, but it isn't.
Since you can't account for the unknown roadblocks and unforeseen surprises, it can be challenging to estimate with confidence. Ideas:
For new development, especially Agile development:
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exuper
If you are estimating effort and time on fixing some nearly impossible to reproduce error(s) in a hideously overly complex system with very few to no developers with intimate domain knowledge of the system then the only correct answer is "When it is fixed."
Typically, I would just tell them the truth. I would tell them they I don't know right now, and I might have better insight in a week. I would then hand them a ball park with as many squiggles in front of it as you can fit on the paper to indicate that it is a gut feeling based guess. If they start hard-balling you, just start every sentence with "It's possible ..." Usually anyone I do anything for is happy with the "Check back in a week or so, but now all I can say is about 2 months" or something like that.
The Personal Software Process (PSP) focuses on improving estimates. This is achieved by disciplined logging of tasks. This, in essence somewhat "accelerates" the "experience" part of estimating since you will have actual data about typical tasks. Of course, this profession still requires unique solutions to many problems but in my experience, estimates are better after using PSP.
