After more than 25 years of professional involvement, I feel qualified to describe how the typical software development cycle works. This is a combination based upon numerous projects that I have observed.

Year 1, January
After months of empty promises, the customer representatives finally feel the need to have something to show the customers. They talk together and decide that the customers really want the same thing, although they don’t know what it is. Therefore, they get together and go through their cryptic notes and write up an unsigned request for unspecified programming changes to satisfy their customers who are threatening to leave and go to the competition.

Year 1, March
Management finally sees request for programming changes and talks to customer reps. They can agree on nothing that they promised to the customer, but put together a list of unhappy customers who are threatening to take their business elsewhere.

Year 1, May
Management calls unhappy customers and promises action on the unspecified requests. Management goes to chief of programming staff and demands for estimate of time to fill unspecified needs. Having nothing to go on, the chief of programming estimates 500 hours or work will be necessary.
He tells management that he is ready to start work immediately. Management says no because the project has not been authorized in the budget for the year. Programmers go back to telling jokes and billing their time in 15 minute increments to “Administrative overhead”.

Year 1, September
Management submits project to budget committee.

Year 1, November
Budget committee approves 350 and $20,000 hours for project.

Year 2, January
New budget comes into force, project begins. Chief of programming calls up customers on list and arranges to meet with them to collect specifications.

Year 2, February through May
Chief flies around the country meeting with customers. Chief gets severe hangovers at each stop, comes back with jumbled specifications. So far 500 hours and $30,000 have been consumed, out of 350 hours and $20,000 authorized.

Year 2, June through August
Chief comes back in time to learn that the project is over time and budget. Chief explains the situation and budget committee approves an additional emergency allocation of 400 hours and $30,000. Chief spends rest of the summer writing up specifications. Finally, specifications are sent to customers for their approval.

Year 2, September
Customers read incomprehensible specifications, are assured that the specs mean whatever they want them to mean, and sign off.

Year 2, October
Budget committee authorizes and additional 800 hours and $60,000 for next year, but nothing more for current year. Project put on hold until next year. Programming staff goes back to telling jokes and surfing the Net.

Year 3, January
Chief of programming quits to form own consulting company. Fortified with new budget, the programming staff begins to try to decipher the specifications and figures out that nobody but the author could possibly do it.

Year 3, February through May
Former chief of programming is re-hired as a consultant at three times his previous salary to run development project. A functional specification is written. He begins to decipher his specifications and dole out work to programmers.

Year 3, June through December
Programmers grind through specifications attempting to make sense and code from them. Former chief, then consultant, leaves for another company, leaving project without leadership. Oldest programmer is appointed chief of programming and project stumbles along. Coding and testing are finally completed.

Year 4, January through March
The few customers who demanded changes and are still with the company are invited in to see a demonstration of the new software. They all agree that it does remotely resemble what they wanted. More of them move to the competition. Meanwhile, several of the customers who left for the competition have become disgusted with said competition, and have returned to the original company, demanding further changes.

Year 4, April through September
After numerous meetings with customers, a new specification is developed. Work stops until the beginning of the new year because this year’s budget is exhausted. Programmers resume kibitzing and surfing the Web.

Year 4, October
Budget committee approves 15,000 hours and $9,000,000 for project.

Year 4, November and December
Four new programmers are hired to begin work next year. Nothing else happens except telling jokes and more web surfing.

Year 5, January
Programmers get started in deciphering new specifications. Coding is doled out and work begins again.

Year 5, February through July
Coding continues at a furious pace, with overtime and weekends taken up with more work.

Year 5, August through October
More customers leave, others arrive demanding changes in specifications.
Budget for next year is set for 20,000 hours and $12,000,000.

Year 5, November through December
Work continues apace.

Year 6, January through June
Coding is completed, testing is begun.

Year 6, July through September
Coding is finally completed and tested. Customers are invited in to see new, improved system. With some reservations, they are pleased.

Year 6, October through December
System is installed and bugs appear throughout. Programmers work overtime to fix bugs. Finally, customers grudgingly accept the system.

Year 7, January
After months of empty promises, the customer representatives finally feel the need to have something to show the customers. ………. And so on.