Developing Software On Time (It Is Possible)
by Charles Connell
Suppose you want a new house for your family to live in. You call a contractor and say, "I need a new house. I want you to come over and start on Monday. While you are working on it, I'll meet with my spouse to figure out what we want. We'll try to have that meeting soon, unless we get busy. And it has to be all done in six months."
Anyone who ordered a house in this way would be asking for trouble. Unfortunately, computer software is specified and built like this all the time. To see the effect on software, imagine what would happen to the house. The project would be behind schedule from the start, but you would not know how far behind. You probably would have to change the foundation and move some walls before you were done. And in the end, you probably would have a lousy house.
Intelligent managers and engineers run software projects in this style. Why? Because we have started to believe that software development is substantially different from other engineering disciplines. In fact, the only difference between software and other forms of engineering is whether we can see and touch the final result. If we could see software, it would lose a lot of its mystique.
Just like a house, software can be planned well, finished on time, and completed with high quality. Here is how:
1. Make decisions about the software -- Understand your organization's internal or marketplace need for this software, and how the software is going to meet it. Research possible features for the software and decide which are most important. Decide which features are desirable, but can be deferred until the next version. This planning should be a combined effort by managers, engineers, and future users of the software.
An objection that is often raised about a careful software planning process is that users' needs and the marketplace are changing too quickly. The same can be said for many physical construction projects, however, but new buildings are erected while a company's space needs are changing.
The key to managing a rapidly changing environment is to shorten the software release cycle. Create an initial version of the system with a relatively small set of core features that are unlikely to change. Then respond quickly to new system requirements in the next version, and the next.
2. Make a realistic schedule, primarily written by the engineers -- The software engineers who will create the system should write most of the schedule for the project. Engineers should ask themselves, "How long is this really going to take?" They should include time for working out details that were not specified in the original planning, programming from start to finish, internal testing, external testing, inevitable small changes, several debug/fix cycles, and performance tuning. They should allow time for vacations, people getting sick, computers breaking, and personnel turnover.
Managers should avoid pressing engineers for the schedule management wants to hear. They should press for a realistic schedule and evidence that it is realistic.
3. Believe your estimate -- This step is often painful for managers, especially senior managers. Realistic software development estimates often are longer than management hoped for. If the truth is that a project will take 18 months rather than eight months, however, you are better off knowing it now and communicating it now.
If, for business reasons, the estimated delivery date is simply too late, you can revisit Step 1. Take a hard look at the intended features and engineering resources, and change something so that the software can be completed more quickly. Do not fall into the trap of changing the schedule without changing the system definition or people assigned to it.
4. Stick to your plan during development -- As soon as you begin development, you will face pressure to change the basic tenants of the system. Barring a dramatic change in underlying business fundamentals, don't do it. Learn to manage users (and the press and analysts) who want everything right away. Politely tell everyone that you are adding their requests to the list of features for the next version.
What about users who control your job and won't take "no" for an answer? In this case, you may need to revisit the Step 1. Key users of the system should have been involved in early design decisions. If the planning process broke down, you may need to do it again. If so, be sure to write a new, realistic schedule based on the new system definition.
5. Reward engineers for making accurate estimates -- The process described here relies on time estimates made by engineers. This is a change from many programming methods, which push schedules down the chain of command. For the new process to succeed, engineers must treat estimating as a key part of their jobs.
The way to achieve this is to back it up with money. Consider making a semiannual bonus of 3% of salary dependent on meeting software development schedules. To control overall compensation, you can implement this plan in place of next year's salary increase. A key requirement to tying compensation to estimating ability is for management to follow Step 4. The system that engineers finally deliver must be largely similar to the one for which they wrote the estimate.
6. Learn from past projects -- The development method described here will lead to better software and more accurate scheduling. No method is perfect however, so you should "tune" this process over time based on your company's experience. For example, the billing department may not like an invoicing feature because the user interface is awkward. For the next version, you can spend more time prototyping this interface before coding.
If you were going to erect a new headquarters for your company, you would never dream of beginning work without a clear idea about the building you want. Then, you would create a realistic schedule. Once construction started, you would generally stick to your plan. The result would be a controlled building process, with a known result in the end. The same principles apply to good software development.
(NOTE: This is the text of the article as submitted to the Boston Globe. The published version was shortened somewhat during editing.)