Daemon does a lot of time and materials work for clients from operational support and maintenance through to feature development. If you're not careful you can die from a thousand cuts as you keep estimating work that folks never follow through with.
A developer cannot provide an estimate on any issue without first investigating the issue. Some issues will be simple to address and should be addressed immediately. Others will be more complex and once investigated should give an indication of the total time required to address. In any event, if the work is performed under time and materials and any time spent estimating should be charged.
As a consequence of these bug-fixing realities we recommend the following to t&m clients:
- A. Anything under 4 hours should be addressed immediately. Any work under four hours typically takes as much time to investigate as it does to address. Not addressing these tasks immediately will significantly increase the cost of repairing these minor issues.
- B. As soon as we realise an issue will take a substantial amount of time (ie more than 4 hours) we estimate and await approval. Given budget constraints, its useful to know what might represent a significant time sink and have the option to re-prioritise the work accordingly.
The problem with bug fixing is that its almost impossible to accurately determine how long it will take to fix until you work your way through the code and understand the nature of the bug. This can take anywhere from minutes to hours.
It is highly likely that many issues will take a lot less than 4 hours to fix or estimate. From experience we find that 4 hours is a good cut off point -- if you can't fix a bug in 4 hours then it may actually be an enhancement, or it needs greater scrutiny to determine whether or not the developer should be persevering with a fix at all.
In any event, at the end of that discovery period the client has much more than an estimate. The outcome includes recommendations for addressing the issue, alternative approaches to the problem or at the very least a list of things the bug is not.
Immediate estimates based purely on the user's account of the bug are nearly always wildly inaccurate.
With this approach to time and materials development we're aiming to be as transparent and as pragmatic as possible by addressing issues as soon as a solution is known, or giving realistic estimates as soon as we have a proper understanding of the underlying problem or request.