Posted: 6/26/2005 5:17:00 PM EDT
|
As part of my company's mandated 80 hours of employee training  , I have decidedto focus on my software project estimation skills (or lack thereof). Every release, I manage to under-estimate the time required to code a project which forces me to work 70 hour weeks to make it up. As the lead developer on the team, I'd like, just once at the end of a release, to be able to scramble to help others get their projects done, rather bust my hump on my own. So, can anyone recommend any good books or online resources on software project estimation? We have to have a couple of software consultants in the ARFCOM army... |
|
Here's a new book that might help you. www.sw-estimation.com/ I've always had pretty good luck breaking large projects down into small blocks that I can easily estimate and then add them up and multiply the sum by a constant. The more people on the project, the larger the constant.  |
|
A couple of interesting reads: 0) The Mythical Man-Month 1) Rapid Development by McConnell 2) Debugging the Development Process by MaGuire OK, these are all more project-management, but you have to have some clue about how to run the project if you're going to predict how long it'll take to run that project. MMM is a classic and a must-read. Not all of it still applies. but there are lots of brilliant bits. For example, suppose you have four people on a project that looks to have 6 months to go, but you want it done in 3 months. So you add 4 more people. Guess what. Now it might take 10 months. By adding people, you actually decreased your existing team's productivity by forcing them to spend time bringing the new guys up to speed. And since you have more people you'll need more meetings, so there's less productivity there. Most Software Engineering wonks insist that dramatically increasing time spent on very formal requirements analysis and formal design phases plus lots of formal sign-offs. You produce a requirements document, then a business spec document, then a tech spec document, then a tech design document, and you start coding from that. This is called "waterfall" methodology, because it's like a river with a series of waterfalls, and many people feel this is the Only True Methodology to use. Rapid Development points out that one problem with waterfall is that you get screwed up if a new business need emerges when you've already coding -- you have to go back upstream and redo a whole lot of stuff. Rapid Development descripes several methodologies, their advantages, and disadvantages. A killer is that your boss is going to want to know how long until coding and testing is done, but you're being asked this before design has even started! It's like asking a contractor how much to build a house before telling him how many square feet, bathrooms, etc. Rapid Development gives several options of how to work with this, but there are no magic solutions. Or you could do what I've done. Take your best guess, double it, and round up. |
|
I recommend "Slack" by Tom DeMarco. This won't help you estimate better to avoid the 70 hour weeks, but it might help you step back and understand what is creating those 70 hour weeks in the first place. In general, I think 70 hour work weeks come from poor management. That can be you not allowing time for things not going right the first time, or it could be your boss emphasizing that if your team isn't working 70 hour weeks, they're not trying as hard as the other teams. I got this book after successfully completing a project that was doomed to fail. I put in many 80+ hour weeks in order to make it happen. I recognized a lot of what we were doing failed to help achieve our overall objective, and read a few books on project management to get a better feel for how people who claim to have many years of experience can make simple and obvious mistakes. People were so glad that this project succeeded that they patted themselves on the back and ignored the cold, hard facts that allowed it to succeed. Every member of our team was an hourly contractor and our project had been given a blank check. We were also lucky enough to have a team of people who all got along well, knew their stuff, and weren't afraid of making too much money. Estimating is the art of pulling numbers out of your ass. Every single methodology I have seen breaks down to doing exactly that. I have never had anyone ask for an estimation and care what went into it. More frequently than not, it's just a game of "I'm thinking of a number, you have to guess what it is." I believe a project plan is a document that is designed to allow one level of management to lie to the level above them, but with enough detail to be believable. I also think it's the least valuable part of the project. It encourages things like status reports, which coincidentally have nothing to do with finishing the project. You need people to be comfortable enough to come to you and let you know they need help. The rest of the time, you need to let them do their work. In companies that don't allow this to happen, add a multiplier for the amount of time needed. If you need to give weekly status reports, multiply your estimates by 2. If you need to give daily status reports, multiply by 100. The hardest thing to get through to paper pushers is that time spent on not-achieving-the-goal increases the overall time needed as well as demotivating the people who are supposed to be doing the work. "Death March" by Edward Yourdon is another good book on project management. It directly addresses the causes of the 70 hour weeks and how to handle such projects. Most projects these days seem to have less than half the resources needed to succeed. This book addresses the causes and effects of this type of resourcing. It also helps give tips on how to focus your time better to make it to the end of the death march style project. "The Career Programmer: Guerilla Tactics for an Imperfect World" by Christopher Duncan is a good book for those managing or working on software projects. It provides a lot of real world examples that many of us will be able to relate to. Also, everything by Scott Adams (Dilbert author) is good because there are many good points interspersed with humor. Another thing that has been very helpful to me is to look at what we're doing and how that compares with Dilbert. If Dilbert is making fun of something we seem to be focusing on, chances are we're not seeing the side of why our actions are ludicrous. When you get tunnel vision, it's time to step back and look at what you've got. Also, reading Dilbert keeps you from taking yourself too seriously, which should help tune down the suicidal thoughts during your death march. Just remember, when you start a project, you know the least you will ever know about that project. When you finish, you'll know enough to do it right next time, if anyone cares enough for there to be a next time, or even ongoing support for the project you finished. The most common problem I have seen is people taking the problem they are assigned, breaking it down into tasks, doing those tasks, and realizing that they did each task right, but those did not solve the problem. As the lead developer, you need to maintain focus on getting the original problem solved. When one of the tasks seems like it's going off on a tangent, don't be afraid to start over keeping in mind your goal and what you have learned in the process. |