Three

I am very, very bad at estimating how long software will take to write.

When I was very young, my mother was concerned that I never laughed or smiled, and having forgotten to pre-load my positronic net with the "humor" module, she realized she would have to do some work from scratch. I am told that the original transcript went something like this.

Mom: Do you know how humor works?
Me: No.
Mom: I am going to tell you a joke, then. It is one of the first jokes that my brother used to tell.
Me: Okay.
Mom: How many balls of string does it take to get to the moon?

Now, my mother actually kept balls of yarn in various places around the house, and I had seen the moon, so this didn't strike me as very funny. I thought about how big balls of yarn were, how surprisingly long they were when unrolled, and how slowly they got smaller. Then I attempted to mentally estimate the distance to the moon, in terms of how quickly the balls unrolled, how quickly they got smaller, pictures in books of the relationship between the moon and the earth, and how far away other things I had seen were. I don't remember the rest of the conversation, but I distinctly remember the mental image that I built during this process, as it has stayed with me during the years. It looked like this:

and so I replied, without a trace of irony,

Me: Three.

My mother thought this was hilarious, so my initial understanding of humor was that I should run up to everyone I met and say: "howmanyballsofstringdoesittaketogettothemoon?doyougiveupyet?THREE!HAHAHAHAHAHAHAHAHAHA". Reading doc/fun/Twisted.Quotes in the Twisted distribution can show you how little it's progressed since then.

When I estimate programming tasks, I still have a similar sensation to when I was 2 years old and building that little picture in my head. Then, I grossly underestimated because I didn't have a mapping between astronomical distances and inches, because I didn't know what units distance was measured in among the stars. Now, I grossly understimate because I don't know what unit you can measure programming effort in. It's not "hours" because I can't reason about that - one does not do a uniform amount of work within one hour on a program, especially since several hours are spent thinking. I know various ways to measure finished programs, and I know of various ways to measure programs by specifying them to death - however, neither of these gives me the accurate estimate when I want it, which is to say, before work has begun and a great deal of resources have been invested. It is harder, and takes longer, in my experience, to accurately estimate (in hours) how long a program will take than to just write it in the first place; and even if you do go through that process, you can't estimate how long the esimation will take (and the estimation process cheats, by stealing work from the programming process so that it is shorter.)

All this thinking doesn't do anything to make the need for good estimates go away though. So how do you tell how big, or how hard a program is, without first writing the program several times and getting lots of different people to do it? When you know how hard it is, what units do you express it in?