Table of contents
Fred Brooks was one of the first people in the world to receive a Ph.D. in computer science. In 1999, he won the highest award in the computer field - the "Turing Award", and in 1985 he was awarded the National Award of Technology. He has worked for the US National Science and Technology Agency and the Defense Science and Technology Council.
By chance, I saw the book "The Mythical Man-Month", which mainly discusses some core concepts in software engineering, such as project management, software complexity, teamwork, and schedule planning. This book puts forward many classic software development principles, some of which are famous "No Silver Bullet" and "Surgical Operation Team" have been named classics so far. Later, he compiled the articles and published this "Mythical Man-Month "Classics.
background
At the end of 1961, IBM planned to implement a major project called "360 System Electronic Computer Project", which required an investment of about 5 billion US dollars. However, this project faced greater challenges, mostly centered on the software side. IBM's goal was to ensure that all software would run on its 360 series computers, a philosophy that caused great confusion for software engineers.
In order to achieve this goal, IBM had to invest a lot of resources, which exceeded the cost of hardware research and development. More than 2,000 software engineers worked on the project, spending more than $500 million in funding, an unprecedented number. The software portion of the project proved to be a huge challenge, but IBM's steadfast commitment to ensuring that their 360 series computers could support a wide range of applications had a profound impact on the computing industry at the time.
When developing the 360 system electronic computer project, due to lack of experience in large-scale software development, the development team fell into one of the most difficult software development dilemmas in history, and ultimately failed to fully realize the original vision.
When the plan to develop this new operating system was first proposed, Frederick Brooks (Frederick Brooks) was one of the most staunch opponents, because he believed that the project was too difficult to be practical. In the end, however, he accepted the great task.
Brooks later wrote a book called "The Mythical Man-Month" (The Mythical Man-Month) based on the experience of this development task. Bible". In this book, he shares insights and lessons about software development, highlighting challenges in human resource management and the software development process. This book has had a profound impact on the understanding of complexity and management issues in software engineering and has become an important reference in the field of software development.
Perception and harvest
Software development is a huge and extremely complex project. Typically, we work on this kind of project as a team, as it helps improve efficiency and saves time. However, with the increase of project participants and the refinement of the division of labor, the need for communication between people increases exponentially. Soon, you will find that the time spent on communication gradually exceeds the time saved by division of labor. In short, as the number of participants increases, the situation is not more favorable, but more chaotic.
Surgical Group
Among them, the author discusses how to form a team in the third chapter. Brooks compares a good software development team to a surgical team, and defines the role of each member of the development team accordingly. In a team, there are multiple roles:
-
The role of the chief programmer can be compared to that of a surgeon. They are personally responsible for formulating functional and performance technical specifications, programming, writing source code, testing, and writing technical documentation.
-
The deputies act as the surgeon's back-up and are able to do any of their jobs. The primary role of the deputy is to provide design ideas, discussions, and evaluations. The lieutenant often speaks for his group in feature and interface discussions with other teams.
-
The administrator's role is that of a professional manager responsible for finances, personnel, workplace arrangements, and equipment. Administrators act as a point of contact with other administrative departments in the organization.
-
The editor's responsibilities include analysis and reorganization based on the surgeon's draft or oral description, providing various reference information and literature citations, overseeing the document generation process, and maintaining multiple versions.
-
The team needs two secretaries, one as an administrator and one as an editor. The administrator's secretary is responsible for project coordination and consistency, not product documentation. The editor's secretary assists the editor.
-
Program staff are responsible for maintaining technical records for all teams in the programming product library. They receive secretarial training and assume administrative responsibility for both machine-coded and human-readable documents.
By specializing programmers, programmers can get rid of tedious paperwork, and at the same time can organize this work to ensure quality and strengthen the team's most valuable asset-the work product .
no silver bullet
The term "silver bullet" stems from European medieval legends, as many of you may know from the movie Underworld. It refers to creatures like werewolves that cannot be killed by ordinary bullets, only silver bullets can destroy them.
Later, the term "silver bullet" was later used metaphorically to describe methods that were particularly effective and seemed to solve problems. Later, it was widely used to refer to those methods that can solve problems quickly, a bit like the "miracle medicine" sold on the streets. "Wonder medicine" refers to those medicines that claim to cure all diseases, which are obviously unrealistic and usually deceptive.
Therefore, there is no silver bullet mentioned in the book, which means that software engineering is an extremely complex system, and there is no special effect method that can improve efficiency forever. The same goes for all things complex, whether it's starting a business, working on a project, or raising kids. The problems we face are unique, the resources to solve them are unique, and the opportunities are unique.
So, really good problem solvers never look for a one-size-fits-all solution, they just build themselves into a unique system that is good at clearly defining a problem and then iteratively solving it .
During this process, always remind yourself that "there is no silver bullet in this world".
Quantification of risk and value
Perceptions of a project's value are often much poorer than its risks. Quantifying risk is inherently challenging, and quantifying value is even more difficult. It seems that quantifying value is usually left to the client to decide, as the book mentions. We often neglect to quantify value for the following reasons: the project is too small and we are not sure how to do it; Future development; this system is just to replace the existing system; the order is issued by the superior, we just need to execute it; the uncertainty of the benefits is too great for us to be sure; the client said: "Trust me, this project is worth doing"; The earnings data itself is also unreliable.
I am deeply aware that the risk of the project must match its value! Quantification of value and risk should be equally important and should be expressed with equal precision! If the value of the project cannot be clearly understood, it is meaningless to simply focus on risk, because we cannot determine whether it is worth taking such a risk, risk and value are interrelated! Risk corresponds to value, and expected value matches expected cost!
Testing and Integration
Careful and detailed design not only makes a product easier to use, it also makes development easier with fewer bugs. Many failure cases stem entirely from aspects of the product that are not precisely defined. Before any code is written, the specification must be submitted to an external testing group to scrutinize it for completeness and clarity. Developers cannot do this work alone. Top-down design with incremental refinement is one of the most important software development methodologies and remains so today, whether for large or small software projects. Excellent top-down design can reduce errors and reduce the risk of failure in four ways. First, a clear structure makes it easier to accurately describe requirements and module functionality. Second, the division of modules and the independence between modules can avoid or reduce system-level errors. Third, the suppression or deferral of detail helps to identify structural defects more easily. Fourth, the design is testable at each stage, so that testing can start earlier and the focus can be gradually placed on different levels. Top-down design does not exclude regression. If necessary, one should dare to overthrow the top-level design and start over.
In structured programming, the control structure of a program consists only of a given set of governing code blocks. System testing should start after all unit tests are done, adding only one component at a time. It is necessary and worthwhile to build a test bench, including creating test code. Someone has to be responsible for change and version control and documentation. Team members should work with a controlled development repository, and the importance of configuration management is self-evident, even for solo development.
at last
Many parts of the article are closely related to our programmers. This book affects not only our daily development, but even our life. It is really inspiring.
attached
If you also like this book, you can buy it through the link below.
The Mythical Man-Month purchase link
