As Easy as Pi

Software Maintenance Blog

William A Clements

As Easy as Pi

or π or 3.1415926535897932384626433832795… or 22⁄7, 223⁄71, 355⁄113 [[1]]

“How though, are pies thought to be easy? They aren't especially easy to make; I know, I've tried it.” [[2]]

With in the first few week of working out side the academic world, I was asked to work on fixing code. My boss asked me to work on several tasks, and to tell him how long it would take. Since I was new to the large software, and had no experience in estimating how long any of the tasks would take, I estimated 2-6 week for each of the tasks. 2 week for a problem that I could reproduce. 4 weeks for adding new features. And 6 weeks for problems that involved removing code and problems that I could not immediately reproduce. Let just say this I did not get any awards for my estimations.

How long does it take to do software maintenance? Any smart programmer, contractor, or professional, will say, “That depends! What is the problem?” Most professionals, (i.e.: general contractor, plummer, car mechanic) I have come across will not get cornered in say how long something will take until they have looked in to it further. Most professionals will not start a task until they understand the whole problem. It is kind of like starting a home improvement project and half way through you realize that you do not have the tools to complete the task. Understanding the whole problem is the problem in most cases.

Scotty: Do ye mind a little advice? Starfleet captains are like children. They want everything right now, and they want it their way. But the secret is to give only what they need, not what they want!

Geordi: Yeah, well I told the captain I'd have this analysis done in an hour.
Scotty: And how long would it really take?
Geordi: An hour!
Scotty: Oh, ye didn't tell him how long it would really take, did ye?
Geordi: Well, of course I did.
Scotty: Oh, laddie, ye've got a lot to learn if ye want people to think of ye as a miracle worker! [[3]]

“How long will this take?”

Rule 1: Investigate first, then solve.

My answer, “I need at least XX days to investigate the problem:
- 2-4 day to understand the architecture
- 2-4 day to play with the software
- 4-8 days to figure out the problem.

Then I will give you an answer on how long it will take to fix the problem.”

Rule 2: Multiply by Pi

Or any other factor, but never what you think it is. To use another Star Trek euphemism:

Kirk: “How long to re-fit?”
Scotty: “Eight weeks. But you don’t have eight weeks, so I’ll do it for you in two.”
Kirk: “Do you always multiply your repair estimates by a factor of four?”
Scotty: “How else to maintain my reputation as a miracle worker?”
Kirk: “Your reputation is safe with me.”
– From Star Trek III [[4]]

No matter how long you think it will take, it will never take that long. What mother actually delivers on her due date? It is better to over estimate, and be the miracle worker, then under estimate and be the “weakest link”.

Rule 3: Record it

Keep a record of how long it takes you to do different software maintenance tasks. This will give you a ball park for estimating. Also keep a record of things that you learned from other people’s code.

---

[1] http://en.wikipedia.org/wiki/Pi
[2] http://www.phrases.org.uk/meanings/as-easy-as-pie.html
[3] http://www.c2.com/cgi/wiki?DiscordantRewardMechanisms , Star Trek: The Next Generation - Relics (1992)
[4] “What Scotty from Star Trek Can Teach Us About Managing Expectations”, Scott Vandehey http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/