As a programmer, I find that project management usually neglects two issues of great importance. Code must be maintainable, and we must implement features in the right order.
Maintainable code is not important just for two years from now, but for two days and two hours from now. Ultimately the only measure of code quality is whether a new programmer can understand it and modify it safely. Unmodifiable code is a constant tax on any other activity. Without quality, all other planning is risky and meaningless.
Scope is always the most flexible parameter in any project. The staffing and schedule are not flexible, and you know it. You won't be allowed to add staff early enough to make a difference. You need to show impressive progress at all times, or your project will suffer a political death before you can ship anything. So you are forced to manage scope. How? You do the most important things first. Don't make the decision yourself, but force your customer to prioritize constantly.
This reality is the essence of Extreme Programming (XP). See http://www.extremeprogramming.org/ , http://www.xprogramming.com/ , and Kent Beck's "Extreme Programming Explained" (Addison Wesley) for much better explanations that I can give. Here are some additional suggestions for programmers.
Insist on short iterations. Two weeks seems to be more than long enough. Three weeks is pushing it. Every two weeks, review what you have already done to make your progress visible. Make it obvious how fast you are going, so no one should be surprised.
Ask your customer to decide what they want to be able to do in two weeks that they cannot do today. Don't ask how they want you to do it, but ask what they want to do. The how must be negotiable. They will tend to describe features of products they have already seen, and you want to be able to invent new ways of solving the problems -- more elegantly and more flexibly.
A domain expert should use the new code every day and badger the programmer about priorities. Experts help avoid wasted effort: "That's a nifty feature, but I can't use it until..." A domain expert can safely exploit new opportunities that appear during coding. A programmer cannot play both roles. Together you can discover serendipitous solutions that were impossible to design upfront.
Keep your project transparent. If you explain something in an email, then put it on your website too. Put your website in your source-control system. Assemble lists of frequently asked questions. Add sample projects and workflows. Invite the entire company to browse your work and try it out. (If information is suppressed for political reasons, then your project is already in trouble. As a programmer, you're better off letting a persecuted project die an early death so you can move onto something more popular.)
Daily ten-minute meetings reveal many opportunities to collaborate. Everyone stands up to encourage brevity. Invite only programmers and those who are using the code right then. Each programmer should describe in a minute or two what was done the day before and what will be done today. Emphasize problems that someone else may have encountered. You'll discover that someone was about to reimplement some existing functionality. Someone will have a simple solution to a problem that could have wasted hours. Programmers will enjoy getting thanked for the most recent improvements in the code. Users of the code can mention new problems they are seeing before the programmers forget what might have been the cause.
Programmers love to debate program style. Ultimately, code is well-written only if it can be maintained. The best way to guarantee maintainability is to involve more than one programmer in the design. Agree that no code in your project is owned by anyone. Encourage each other to modify any code at any time. Of course you want to discuss your ideas will the original authors, but eventually they will no longer be available anyway. Try working without them sooner rather than later. Even easier, try pair programming.
Iteration meetings naturally balance the load of programmers so that no single individual ever becomes "critical path," with everyone else waiting. To balance properly, programmers will volunteer to work on parts of the project that others are too busy to finish. These are excellent opportunaties to see how maintainable the code really is, and to refactor while the original authors are still available.
Bill Harlan, 2001
Return to parent directory.