by Frederick P. Brooks, Jr.
In the first chapter of The Mythical Man-Month, Frederick Brooks, Jr., introduces the field of programming and the inherent benefits and problems with the field. Programming is rewarding and fun because we're building something tangible and something that users in the real world will experience. The act of creation of complex interactions and interwoven parts is intellectually stimulating, as is the learning process that takes place along the process of program development. But, programming large-scale products and systems usually encounter the "tar pit." Large-scale projects get sucked down and do not meet calendar deadlines, have to drop features, or may fail completely. Even the most ambitious and insightful programming projects can be claimed victim by the programming tar pit.
Brooks explains that more programming projects fail because of calendar deadlines than any other reason. This is because estimating progress is extremely hard within a software team. Usually the team will confuse actual effort and time with progress, both because the teams are working hard but not actually producing useable code or because tracking scheduling and progress is done poorly. And when the project gets far behind schedule, the first thing that a programming manager will do is add more manpower. Brooks argues that men can not be interchangeable with months, and using the "man-month" to estimate software development is a dangerous and ineffective process. Because most large-scale systems have sequential dependencies, meaning that one part of the system or testing another part of the system is dependent on the progress of another worker, just adding more men isn't going to solve the problem. You will have to take time to train the new workers in the task you are completing, and the additional communication required (especially in a complex system) will actually make your task later than if you hadn't added any new programmers. The number of months required for a task depends on its sequential constraints, and you can't make that number any smaller by adding more programmers.
The obvious solution is to do all programming tasks on smaller teams, to reduce the time needed for training and communication. But, with large-scale products that might need the equivalent of 5000 man-months to complete, this is not feasible. Brooks presents a model to cut a large system into separate tasks, and reduce the number of people that are in charge and have to communicate. The "surgery team" system is built upon the interactions in a medical surgery room: the surgeon is the main programmer, who does most of the work. The co-pilot is his right-hand man, ready there to give him advice and sometimes do some coding. We also have secretaries, language lawyers to give advice on possible implementation schemes with the programming language, and editors that manage the product's documentation. In all, the surgery team paradigm can reduce communication between 200 works to only 20 "surgeons," making the project more efficient.
I thought the first 3 chapters were particularly interesting and insightful. These are the kinds of things that are written in the Extreme Programming Installed book that we're reading as well, but this book was written in 1975, when there weren't a ton of software companies. I agree that adding more people to a team makes a project much harder, because I am always more happy when I'm working on a small team or by myself. With larger teams, it's really hard to coordinate who is working on what, meeting times, and questions about code. I really like the idea that in a large-scale system we have lots of small groups that are assigned tasks. So that group can focus on their own task with minimal communication with other groups, and one person can be put in charge as a delegate between the other teams.
No comments:
Post a Comment