Assessing how long it will take to write or fix code.

Like all developers, I hate giving estimates as to how long it will take to write some code or fix it. The real problem is that you can’t really honestly know how long it will take something until you’ve solved all the known-unknown and (worse) unknown-unknown problems. And by that time, well–you’re done.

There are, however, rules of thumb we can apply to estimate how long it will take to write some code: a feel for the size of the problem, a vague sketch of the architecture in your head, the mental checklist on the APIs you’ll need to access–and experience allows you to give a rough estimate on how long it will take to write new code.

For me, estimating new code is relatively easy: I have a rough feel for it. But estimating fixing bugs–that’s a whole different animal, because it consists of two sorta-known unknowns:

(1) How do I reproduce the problem? You can’t fix it until you can reproduce it, and sometimes it’s hard to figure out how to reproduce a problem.

(That’s why a good QA or QAE is so damned hard to find, but so invaluable to the development process: a good QA or QAE can give you specific steps to reliably reproduce a problem. It’s also why a well-written bug report must include specific steps which reliably reproduce a problem.)

(2) Is the problem a simple fix? Or am I going to have to rewrite something? Sometimes a bug is as simple as “oops, forgot to set up a variable before calling a routine”–and with good reproduction steps it could take just a few minutes to test, debug, validate, and push out to QA for verification.

Sometimes the problem requires a massive rewrite.

And you can’t know until you know what the problem is.

For me, I estimate these defects based on if the steps to reproduce are simple or if the problem is a vague “it crashes when I wave it through the air,” and if the area in the code sounds (and the nature of the bug) sounds like it’s a “hmmm, I wonder if I skipped an important step” or a “oh, God; do I need to rewrite that module?” And while you can get a feel for it, it’s not an exact science since you’re estimating the time to resolve two sorta-known unknowns (that is, I know they’re unknown, but I don’t know how unknown my unknowns are)–well…

To give a concrete example I got a bug report that said “sometimes it crashes when I start up the application.” Someone asked me for an estimate. I told them “I think it’s a simple crash, but I don’t know how to reproduce it. Maybe two days?”

Then QA privately e-mailed me with specific steps.

And two days became 15 minutes.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s