Tuesday, May 12, 2009

Lawn Mowing and Estimation

I hate mowing the lawn.

I was out mowing the other day and was pondering upon how much I dislike it. I really shouldn't hate it so much, since it's good exercise, it needs to be done, and it makes my lawn look nice (well, "nicer" would be more accurate), but I do. My pondering included thoughts of hiring a professional company and wondering how much it would cost me. I wondered how they would estimate the cost. You see, my lawn, though not necessarily large (well, *I* think it's large), is very hilly (welcome to West Virginia, they tell me).

I wondered how you would go about estimating the cost: whether by size or by time. The way I think, the biggest cost to lawn mowing has to do with time. Specifically, I would expect that it would have to do with direct labor cost (how long someone spent mowing) and how much gas was expended. For some reason, I focused on the gas aspect (given gas prices) and wondered about the best way to estimate its cost.

If you do it by size, it's pretty easy to estimate, given that you can visually estimate the size by merely looking at the yard, itself. However, if you estimate based upon the time it takes, it's easier to run into tricky mistakes. Looking at my lawn, for example, with all of its hills and crooks and crannies, you'd think it wouldn't be too hard. But, after mowing it, I found that it took a *whole* lot longer than I'd anticipated.

Programming is fairly similar when it comes to estimation, though I think the difficulty is flipped. It's difficult to estimate size, but easier to estimate time (at least for smaller tasks). Estimating size in lines of code, of course, depends a great deal on the language, the programmer, and the task at hand. Not all lines of code are created equal. Of course, there are other size tools, such as function points, use case points, complexity counts, etc. The concept is the same, but the measuring stick is different (not to suggest that any measuring stick will work just as well...hence the number of different measures). There are even complex mathematical models that use size to estimate larger projects, such as COCOMO (there are a number of commercial parametric estimation tools that use their own proprietary models).

Estimating time, at least for smaller tasks, is usually straight forward for a programmer with a little experience. But, then, that's been my experience. Time estimation for larger tasks, though, becomes much more difficult...just ask anyone who has had to fully plan out a large project using MS Project or similar tool. So, maybe it's not so different than mowing a lawn...

Either way you look at it, though, estimating helps to measure cost and effort, helping you know how much of that lawn you're going to finish before it starts raining for a week straight...