Wed 22 Aug 2007
The Perfect Estimate
Posted by Scott Westfall under Dev Management, Programming
[5] Comments
We’re doing the planning for SlickEdit 2008 now, so I have estimates on my mind. Most programmers would prefer to avoid estimates altogether. They prefer the “we’ll let you know when it’s done” approach to scheduling. Providing estimates and making schedules are the biggest differences between software as a business and software as a hobby. Well, that and sales, and budgets, and …
Whether you like it or not, providing software estimates is probably part of your development process. If you’re lucky, your estimates actually feed into the schedule that determines when the project will be delivered. Often, that date was determined by the sales and marketing team long before the requirements were written and you were asked to provide your estimate.
Someone unfamiliar with software development, might think that estimates are produced using complex calculations based on system requirements and complexity. Indeed, such estimating techniques have been developed. In practice, estimation is usually done by rolling your eyes and saying, “Hmm, well, let’s see, I think it’s going to take about (insert wildly inaccurate estimate here).”
This process is often called taking a SWAG, where SWAG stands for “Silly Wild Ass Guess” or “Statistical Wild Ass Guess”. In my junior years, I was taught that SWAG stands for “Super Wild Ass Guess” to distinguish it from a WAG, which stands for “Wild Ass Guess”. When delivering estimates, it was customary to identifying whether it was a WAG or a SWAG so your manager knew how much to panic.
You’ve probably heard that when making estimates you should take your best guess and double it. It’s also common knowledge that standard practice for many managers is to cut all estimates in half. This leads to the question: are managers cutting estimates in half because developers are doubling them, or are developers doubling their estimates because their managers are cutting them in half. Regardless, this system can only work if both parties are mutually distrusting.
Today, I will share with you what I have learned through 20 years of giving and receiving estimates. The perfect estimate for most tasks is two weeks. It’s long enough to be plausible and short enough not to be objectionable. Of course, you can’t get most things done in two weeks. When the two weeks is nearly up and your manager asks you how you are doing, simply explain that you ran into some problems and that you’ll need more time. When he asks how much, tell him, “two weeks”. You can usually repeat this process a couple of times before it becomes an issue. I once worked with a guy who delivered an entire subsystem in 6 months on a series of 2 weeks estimates.
I’ll put some more posts together on estimating, hopefully something a little more helpful than this tongue-in-cheek post. I think I can have it ready in, oh, two weeks.
–Scott Westfall
August 22nd, 2007 at 10:36 am
So I see management at SlickEdit are also wedded to the incredibly stupid method (ISM) of doing software? That is, (1) pick a ship date, (2) pick a product name, and (3) only then figure out what you need to build? Yuck. I pity you. I’ve done enough of that.
August 22nd, 2007 at 11:35 am
When I picked up the SWAG acronym, the S meant Scientific. 🙂
August 22nd, 2007 at 1:37 pm
Phileosophos,
SlickEdit is committed to an annual release cycle, which works very well for us and our customers. As a mature product, most of our changes are incremental and fit well within this framework. Our customers know that each year they will receive a release with new features and bug fixes. We also release smaller updates as needed to address issues that don’t fit this schedule.
I agree that this model doesn’t work for all products, particularly those in their first release or ones making major overhauls. However, setting a release date is always a part of the business of software development. As much as we’d like to have this date set solely based on when the software will be ready, the reality of the business must be factored in.
For new products, you have to factor in market windows, capital burn rates, annual sales cycles, etc. It’s no good to release a product after the company has already gone broke or someone has beaten you to the market. For existing products, there are also business pressures.
As developers, it’s our job to work with the business team and discuss what can be built in the available time. Where more time leads to a better product, we need to show them that and provide them with the ability to choose what makes sense for the business. That’s why I believe estimates are so important.
Effective estimates enable a company to plan releases and commit to release dates far in advance. This allows all of the business functions, like production and marketing, to work toward the same date, culminating in a successful release.
This article didn’t really touch on these subjects, but I hope to write more on this in the future.
August 23rd, 2007 at 8:18 am
You’ve probably heard that when making estimates you should take your best guess and double it.
You missed the step of changing to the next highest unit of measure 🙂
A one hour job inevitably takes two days, and a week task two months!
January 1st, 2008 at 3:03 am
It was rather a fun reading this, keep it up, gd work.