by Frederick P. Brooks, Jr.
In Chapter 10 of The Mythical Man-Month, Brooks Jr. addresses the issue of how much documentation that a manager should keep for themselves, and what important documents are needed. The concerns of any manager are the "what", "when", "how much", "where", and "who". In a software development setting, these correspond to objectives of the software and produce specifications, schedule, budgeting, space allocation, and an organization chart that assigns tasks to different programmers and managers. It's important to have these kinds of documents because writing down helps inconsistencies and gaps in the design process to come out. Those documents also serve as a way to communicate to everyone on the team the decisions that have been made about these issues, because oral communication and emails may not have circulated around to everyone. But, the manager must realize that these documents are only about 20% of the management tasks, and that the other 80% is spent guiding and encouraging the programmers on the team.
In Chapter 11, Brooks Jr. talks about the very first part of the software project that is built. Usually, after some design and meetings, the programmers start working on the project and writing code. Algorithms are proposed and refined, and they find out that the functionality that they wrote works and is ready to be written into a larger-scale program. Brooks says that the teams should always "plan to throw one away." This means that whenever you first start programming, you should have in mind that this first release is tentative and will get thrown away. Then, you can start over with a better idea of what you want to accomplish, and know what works and what doesn't. If you stick with that first draft, you'll end up releasing a slow, buggy, and hard to use system to the users and end up having to redesign the product anyway. Brooks talks about how each system starts out "taking two steps forward and one step back." This means that continued releases add functionality but are hindered just a bit by bug fixes. But after users get more familiar with the program, more and more bugs are found, and the system is just taking "one step forward and one step back." This means that no matter what functionality you add, the bug fixes end up destroying that functionality and the structure of the system. This is why you should throw away the first draft and start over, and not waste time upgrading software that is essentially already dead.
In Chapter 12, he talks about the tools that a programming team will use, and how their organization and selection can greatly increase the efficiency of the project. First, he says that each programmer shouldn't use their own set of tools, because they hamper communication and can cause differences in the code produced. As each team has different things they're working on, specialized tools per team are necessary, with a toolmaker designated per team that decides what tools to use and trains the team in how to use them. One important tool is the target machine and the vehicle machine for the program. The target machine is what the product will be run on, and the vehicle machine is the machine that the development will be done on. Programming libraries, source control, text-editors for documentation, and the language used are all important tools vital to the success of the project.
Again, a lot of the ideas in this book are fairly outdated. In keeping with the XP tradition, I do like that Brooks proposes a smaller set of documents instead of the giant product book that he talked about in earlier chapters. This way you can spend more time programming and less time making changes in all of the documentation when design issues come up. I agree that the first draft of a product should usually be thrown out, and it's always good to start again. The problem is that whenever you work that hard on a project, it's hard to throw that away, and also hard to start a new project without doing the exact same work that you just finished. Lastly, he spends a lot of time talking about scheduling for machines, which isn't as relevant today. Maybe there are still groups that do research on supercomputers, but today usually each person has their own computer to program on and possibly their own server to test on as well.
No comments:
Post a Comment