No matter how tough the technical assignment may be, it's almost always the easiest part of delivering a product. Ironically, one of the most difficult tasks to do well in our business sounds almost trivial when mentioned. Nonetheless, there is no greater look of trepidation in the software industry than that on the face of a seasoned programmer who's just been asked to offer an estimate for a software project. If you think an IRS audit is scary, you just haven't lived until someone takes a timeline that you pulled from the clear blue sky and has it chiseled in stone, displayed in big, bold letters for all upper management to see. The only reason this hasn't been the subject of a major motion picture is that Hollywood blows as many deadlines as we do.
Probably the oldest trick in the book is the time honored Multiply By Two technique. With this approach, you take a day or two and take a swing at how many days / weeks / months you think it will take, and then multiply that number by two. Your manager then employs the executive version of this method and multiplies your number by two. What you end up with is a calendar date well in the future, with plenty of extra time built in. With such a large contingency factor, you're almost certain to meet the deadlines even if a few things do go wrong. Amazingly though, project after project begins based on this manner of generous estimating and somehow still ends up in the classic deadline disaster of long hours, bad coffee, unfulfilled commitments, angry customers, pointed fingers and pizza that's not delivered in 30 minutes or less. How can this be?
It took me years to come to terms with this one, not to mention enduring a long string of rather exciting releases. We can discuss the cumulative effect of that much bad coffee on my stomach lining some other time. On the positive side, it did reach a point where I was in the best physical shape of my life due to the strenuous requirements of diving feet first with a half twist out of a 4th floor window, catching the window ledge on the way out and then shimmying down the drain pipe, all initiated by the sound of an approaching manager who had just uttered the word "estimate". It was truly a marvel to see, although the wear and tear on my sneakers got a bit expensive. Those corporate brick walls do tend to be just a bit on the abrasive side.
So what's a programmer to do, particularly when we're too old to jump out windows anymore? Actually, it really is possible to create accurate timelines that will withstand all but the largest mishaps. As is so often true, the key to success lies in the details. Well, that and a judicious amount of political maneuvering.
While the details of estimating a software project could easily fill a book, I have some space constraints here and you no doubt have a busy day ahead of you. Consequently, we'll focus on the important points here and arm you with the practical information you need to avoid any out of window experiences of your own. Even so, this particular topic will arrive in two parts. In today's installment, we're going to cover the early stages of the development process that must be handled properly in order to have a firm foundation for accurate estimating. The next time around, we'll delve into the gritty details of assessing effort, developing a timeline and tracking the overall implementation of the system.
If you work in a structured environment that already has its act together as far as the development process goes, you're probably ahead of the game. Take two donuts out of petty cash and check back with us later. Much of what follows is for those of you who work in less than perfect environments and want to improve your lot in life.
While the steps that we'll cover here won't seem terribly unreasonable to those of you who work in engineering firms, it's gonna seem like one monumental pain in the tookus to those of you who work in smaller shops and are used to a fairly loose environment. However, the harsh reality of the matter is that in order to properly estimate your work and avoid both major stress and ridiculous overtime, you're going to have to employ some discipline and structure.
Surprisingly, one of the first steps you must take is one that is frequently given very casual attention. Before you can estimate, you need an accurate and complete list of requirements. Sounds pretty obvious, doesn't it? However, you'd be surprised how many projects start with very fuzzy information in this area. That's a guaranteed deadline killer. No matter how small the project is, if you don't know exactly, to the last detail, what the system is supposed to do then you have no chance whatsoever of accurately estimating the effort. You also leave yourself wide open to the joys of scope creep.
With this in mind, your first meeting should be with those who are driving the project. Read their documents, take detailed notes and ask a lot of very specific and pointed questions about functionality. Most importantly, don't settle for anything less than well defined, specific answers to your questions. In many cases, this is where the trouble begins. If you accept vague answers here, you're toast. You will have no defense against missing deadlines because others will have the ability to continually expand the functionality every time they think of a cool new feature. Your originally stated deadline, however, won't move.
Don't leave any such loopholes in your project. Make sure every requirement is spelled out explicitly, and then put it in writing. Submit your document to those who are in charge of the functionality for their review to make sure you have an accurate and complete assessment of the project. If you can swing it, get them to sign the document as well so you have something in writing to cover your posterior with later (label the signature line Approval, though - they'll feel less threatened by it).
Be prepared for this process to go through a few iterations before you get the final requirements doc. It would also be a good idea to put each subsequent revision of the doc into version control. Once you have a completed requirements doc, you're ready to cough up that estimate that they've been pestering you for all through the requirements phase, right? Not likely. How can you estimate how long it will take you to code something before you've even designed it? We now enter the design phase.
All too often, management was chomping at the bit for a final delivery date from the very beginning, even as you were dragging them kicking and screaming into requirements meetings that they didn't think were really necessary. When you tell them that they still can't have an estimate until you complete the design phase, they may go ballistic. No procedure will survive in the wild unless it's approached in a realistic manner. Therefore, at this point you're probably going to have to throw them a bone just to keep the peace.
There are many steps to a software project but in general they can be simplified down to requirements, design, implementation, testing and user documentation. Consequently, we now have what we need to prepare an estimate for the design phase of the project. Understand, folks, that this has both practical and political value. Of the latter I'll simply say that if you don't give them an estimate of how long the complete design is going to take they're often just not going to let you have a design phase. They're going to lose their patience and tell you to get on with coding the darned thing. The former we've already covered. You can't tell them how long it's going to take until you know what you're going to do in the first place.
Silly as it may sound, there are many people in this business who feel that if programmers aren't coding then they're not working. These people usually aren't programmers themselves, of course. They're in charge of the programmers. Because of this, giving an estimate for the design phase is often a combination of time calculation and collective bargaining. You may have to fight tooth and nail to get even a little time to formally design the system.
Some of you folks who are working in the structured, disciplined development companies are doubtless shaking your heads at this point, wondering what sort of amateurs would start coding on a project without an official and detailed design phase. While I agree with you wholeheartedly, it doesn't change the fact that I'm a mercenary and get paid to make things happen regardless of (or maybe even because of) the problems in the environment. You work with what you've got.
So, if you happen to exist in a similar environment, at this point you take as many days as you think they'll let you get away with and come up with an estimate of how long it will take you to design the system. As unscientific as it may sound, this part of the process is typically more politics than engineering. In a perfect world, you actually have some meetings and whiteboard out the high level architecture of the system, from which you can get a general sense of how long a decent design will take. In your design phase, you'll go down as many levels in the architecture as is appropriate for your design methodology.
In a less than perfect world, you simply ask for twice the time that you think they'll let you have for design, let them throw the obligatory fit about how they just can't afford that much of a delay, bargain from there and take what you can get. That's certainly not the way they do it in all the expensive books, but out here on the front lines we do what we have to do. In any event, you've bought as much time as you can get to design the system, and with this under your belt you finally have the ammunition you need to estimate the implementation.
At this point in the process, many weeks have gone by and you still haven't had to commit to a delivery date. While some of what we've done thus far may sound like playing games with management, in the end nothing could be further from the truth. Our job as professional developers is to deliver what we promise, when we promise. Companies put a lot of money on the line based on us keeping our word and delivering the goods. Unfortunately, these same companies all too often unwittingly sabotage the very development process they're depending on. That can cost money, credibility in the marketplace, even the jobs of good, hard working people who just got caught in the crossfire of poor business decisions. If you keep your eye on the end game and remain dedicated to giving your company what they truly need then you have to be willing to play hard and play to win. Sometimes that means managing your management.
When next we meet, we'll be ready to get down to the nuts and bolts of doing accurate and dependable estimates on the actual implementation phase of the project. Once the compilers are fired up and the coding begins scrutiny will be at an all time high, so it's absolutely critical to give realistic timelines and then meet those deadlines with clockwork precision. While there are still a couple of political considerations remaining, from this point on we get detailed, so bring your favorite spreadsheet and call your bookie while you're at it. We're gonna beat the odds.
Top 