- The small brooks "Mythical Man-Month," the best-selling book 40 years in the field of software engineering management, I see the Chinese 40th anniversary commemorative edition. Compared to the original author added some new ideas and, according to some comments today, the status quo of software engineering management to add, to see which out of date, which is still valid. Also a number of celebrities as well as Appendix reader comments on the book. Overall, the main line of the book - Mythical Man-Month, there is no silver bullet in the areas of project management software today still belongs to a valid basic theory. However, some domestic methodology for software project management environment is not suited for these methodologies we can absorb the essence of the idea, the specific methods reform, Chinese characteristics to create some software project management methods. This is a big topic, I inexperienced, so this will not talk about this. I want to talk to me in this book is the image of some deeper theoretical concepts.
Tar Pits
- Tar Pits is used to describe a concept of large-scale system development. Prehistoric, dinosaurs, mammoths, saber-toothed tiger encounter these large carnivores is no way to get rid of the tar pits, but the harder the easier it is to sink into the bottom of the pit. This scene is like a very large system development work.
All age groups, large or small, complex or lean, one after drowning in a tar pit. The surface looks as if there is no one single issue causes difficulties, every problem can be solved, but when they are entangled with each other and accumulate together, team action will become more and more slowly. For the issue of the extent of the trouble, everyone seems to be in for a surprise, and it is difficult to see the nature of the problem.
- A substantially large development cost of the programming system products would be 9 times that of a single simple process. Herein refers to the product of the programming system may be a combination of many programming interactive application and the system formed by collaboration of the program set. Each of us should clearly realize that such a non-linear relationship, recognize the real large-scale programming system products are not simply stacked simple program. This is the so-called "tar pit."
- Since it is known to be a tar pit, then why should we go jump in? In the book, we list the product development of large systems of fun and distress. For me, I'm in software development fun is:
- Develop its fun something useful to others.
- The face is not repetitive tasks, the fun of continuous learning.
- The greatest distress is that:
- Before the completion of the total product is facing the threat of obsolescence; only when actually needed, will use the latest vision.
Mythical Man-Month
- Estimating software project schedule is often overly optimistic results derived according to the urgency of the project for, this is because all the programmers are optimists, we tend to think "This certainly run" or " I have to find the last bug ", on the other hand is derived from market pressures, the situation in the domestic environment even more. The first mistake we schedule estimates for the assumption is this: everything will work well, each task takes only the time that it "should" take. And this assumption is often wishful thinking, for creative work, the creators often in the implementation process, only to find when the conceptual design of incompleteness and inconsistency, which is fed back to the design concept, to deal with this problem with the time and complexity of the structure and the size will be the task of the project presents a nonlinear relationship increases. So for large software projects, "everything will work well" is a very small probability of things.
- In software projects, we often employing this month workload indicators to measure the project. But the person-months of this indicator is actually a dangerous myth deceptive. It implies that the number of personnel and time can be interchangeable. Only in the case of the task decomposition to the participants do not need to exchange between them, and the number of times is interchangeable. In practice, software project, as long as the project of a certain size, whether it is design, development, testing, deployment, there will be various stages of decomposition of tasks to different people, and these stages themselves belong to one kind of task decomposition, decomposition of tasks between different personnel inevitably lead to an additional cost of communication - training and communicate with each other. Because software development is essentially a system of work - a practice under the intricate relationship, communication, exchange of workload is very large, it will soon consume the savings task decomposition of personal time. In simple terms it is that three people three months to dry things not to say that individuals will be able to arrange a 9 month finished the job. Furthermore, additional staff practice in project behind schedule, often only make progress even further behind. This is in addition to the mythical man-month.
The project depends on the time limit on the order, the maximum number of people dependent on the number of independent subtasks. From these two values can calculate the schedule, there are fewer of the table arrangements, it takes a long time (the only risk is that products may be out of date). Instead, assign more staff to plan short period of time, it will not be workable schedule. In short, many software projects, the lack of a reasonable schedule caused by the project is lagging the main reason, it affects all other factors combined ratio is even larger.
Surgical team
- The face of "tar pit" and "Mythical Man-Month" software project, a solution is given by the authors - "surgical team." Studies have shown that the same two years experience and receive the same training, the excellent professional programmer productivity is 10 times worse programmer. In software projects, a small, elite team is the best, so not only reduces communication costs and increase productivity. But for large systems in the true sense, a small elite team often means too slow. This is where the contradiction, for the integrity and efficiency of the concept, the best by a small number of capable personnel to design and develop, and for large systems, it requires a lot of manpower to make the product in time to meet market It needs.
- In the software project "surgical team" have a similar surgeon's chief programmer. He personally define the functional and performance specifications, design procedures, the preparation of the main framework source code, testing and writing technical documentation. There is also a deputy chief programmer, his main role is as a design thinker, discussants and evaluators. Unlike traditional two teams each responsible for part of the work of design and implementation, the two men "surgical team" in the need to work together to understand all of the design and all of the code. Other programmers and managers, document editors, etc. to achieve specific functions and promote the project around the main architectural design. The benefits of this team is that access to both the integrity of the product produced by a few minds, but also get a number of support staff overall productivity, but also drastically reduces the workload of communication.
- The authors emphasize the concept of the integrity of the software system, also need to ensure that the integrity of the chief programmer or a small team to have a consensus top-down structure of the system design.
To make the work easier to manage, must be clearly demarcated between the design and implementation of systems, system architects must scrupulously focused on architecture.
No Silver Bullet
In the next decade, whether in technology or management methods, we have not see any breakthrough progress, can greatly improve the productivity of software assurance, reliability and simplicity within a decade.
- This folklore wolf monster exists, will become a terrible wolf face a familiar human face in the full moon. We are familiar with the software program also has the characteristics of human wolves, seemingly simple appearance, but may at any time become a behind schedule, over budget, there are a lot of defects monster. Against man wolf only reliable weapon is the silver bullet in folklore. So the silver bullet in software projects is a metaphor that makes the software cost as computer hardware costs as quickly reduce the silver bullet. However, the author tells us that 40 years ago, pessimistic, there is no silver bullet. 40 years later, we looked back, I am afraid that this prediction is true.
- First we have to realize is that software development there are two difficulties, one is fundamental - the difficulties inherent in software features, and the other is secondary - existing, but not innate difficult. For the former problem, there is no silver bullet. The latter difficulty can be overcome by advances in software engineering or management techniques.
Software development is a difficult part of the specification, design and test structures on these concepts, rather than the concept of express and validate the vividness of reality.
- There are four fundamental difficulty inherent in software development - complexity, conformity, changeability and invisibility.
- Complexity is to say in terms of size, the software entities may have more complex than any other entity ever created by mankind. On the one hand, many from the computer itself, the complexity of software systems as well as the state. On the other hand, the various elements of a software system or a non-linear way in increasing the interaction, making the software complexity is also much more than the non-linear growth. Due to the complexity and communication costs, software team members is also very large, also produced a series of technical difficulties, and will lead to many management problems.
- Consistency is actually right software compatibility, we developed software often in order to keep the number of human practices and systems must follow, it must maintain its consistency for these interfaces.
- As long as people in the software industry should be able to understand the variability of the software, because the application, various changes in user habits, social laws of nature, computer hardware, etc. will relentlessly continue to force the software will change accordingly. There is a saying that the only constant is change possible needs in the software industry.
- Visibility is not to say the software does not have the physical characteristics of the space on the objective existence, can not be visualized. Whether it is a timing diagram of a flow chart or software engineering, etc. used in the charts are not the same as giving all users a complete concept as a whole map or schematic. So that some of the concepts between designers and software developers in the design can not be complete and clear communication.
- Modern software engineering through high-level language, time-sharing systems, object-oriented programming, using the new theory and practice of open source libraries, such as agile development to overcome the minor difficulties continue in software development, but also alleviate some of the fundamental difficulties. But still can not eliminate the fundamental difficulties such software complexity. Because of the complexity of software tools with the continuous improvement capabilities, software development need to face the fact, also in the rising. So, we have to enhance productivity in the software needed to be gradual progress, not expecting a breakthrough overnight.
At last
Tar Pits software engineering will continue to make it difficult in the future for a long time, unable to extricate themselves. Software system may be created by mankind in the most intricate things can only expect people to explore and try in just beyond the limits of its resources in whatever living. This complex industry needs: ongoing development; learning to use more elements to develop; the best use of new tools; the best application by the project management method of argument; good self-judgment and the ability to make us aware of their inadequate - God-given humility.
