The Mythical Man-Month by Frederick P. Brooks, Jr.

This article was inspired by Frederick P. Brooks, Jr.'s The Mythical Man-Month . If you enjoy this article then consider purchasing or borrowing the book.


Lessons from Software Engineering

“How does one control a big project on a tight schedule? The first step is to have a schedule.”

Programming dispels the myth of the “man-month” – the idea that a project manager can divide the work up successfully among workers over a period of time without deviating from this plan. Like other intellectual tasks, developing software requires constant communication among workers, so adding new programmers to the project can slow progress by creating more work.

Techniques for handling programming projects vary, but one strategy involves setting up a “chief programmer.” Those who work under the chief programmer carry out the tasks that best suit them. Most importantly, a program must have “conceptual integrity.” In other words, either one person creates the software, or a team needs to agree on the vision for this program.

Both physical architects and software architects fall into the same patterns. In the initial phase, their work will be the bare bones of their original ideas. By the second version of their work, architects try to implement all the ideas they had in mind, leading to a creation bogged down by superfluous materials. Acting in moderation, the architects develop the best version on their third attempt.

Software must be documented, so that others can actually use it. Your explanatory manual must omit details users don’t need to run the program, and it must unambiguously describe the process of using the software.

Hold regular meetings to keep your team on track, and have an annual meeting that addresses the problems that have arisen over the year. Communication is essential! Documentation may seem unnecessary, but records allow you to see errors in your thinking over time. Some aspects of documentation must be used during projects, whether they are software engineering projects or running a school.

To make your goals and standards understood by everyone involved in the project, create a “project workbook.” All kinds of projects require schedules and budgets. The program’s running time and size will affect the budget.

Projects often fall behind schedule over time, so you should establish specific milestones in a “Program Evaluation and Review Technique” (PERT) chart, which will demonstrate what delays affect later activities. If your subordinates have the drive to make up for lost time, you will stay on track. Instead of getting in their way, let your workers meet the project’s goals as they arise.

Structure your organization, so that you are prepared to throw away the first version of your program. Since your team’s understanding of the program will continually evolve, develop an adaptable approach to the project.

Project managers must be prepared to shift workers among jobs when necessary. Understand that bugs will inevitably creep into the program. Design and test your program from the top down, and always focus on conceptual integrity. You will probably need to allow as much time to debug the program as it took to develop it. Think of programming as an art form, and always encourage the artists working for you.

QR Code
QR Code lessons_from_software_engineering (generated for current page)