Excerpts from the same point of view (part)
Brooks' views are not necessarily golden rules now, but we have to analyze which ones are objective laws and must be followed; which ones need to keep pace with the times; we should add some benefits to Brooks' views.
Chapter 4 Aristocratic Despotism, Democracy, and System Design
4.1 "Conceptual integrity is the most important consideration in system design".
My understanding: Conceptual integrity is one of the most important issues for the system, but it seems that in the field of development around, very little attention is paid to it.
4.2 "The ratio of function to understanding complexity is the ultimate test criterion for system design", not just rich functions. [The ratio is a measure of ease of use, validated by both simple and complex applications. ]
My understanding:
When designing requirements and design, design complexity, implementation complexity, operation and maintenance complexity, learning cost and usage complexity must be considered, and it is best to reflect and confirm in the document.
4.3 In order to achieve conceptual integrity, the design must be done by a single person or a small team with consensus.
My understanding:
See an anti-pattern: Design by committee : Lots of people designing at the same time without a unified view. Even if they compromise and agree with each other, it is a cauldron of mixed vegetables.
4.4 "For very large projects, decoupling the design methodology, architectural aspects of the work, from the concrete implementation is a powerful way to gain conceptual integrity." [Applies to small projects as well. ]
My understanding:
Unfortunately, very few can do this now, and even fewer leaders have a full understanding of this.
4.5 "If the conceptual integrity of the system is to be attained, the concepts must be controlled. This is effectively a kind of aristocratic despotism without any apology."
My understanding:
the way everyone is involved in the design and the autocratic design of senior people reminds me of politics.
4.6 Discipline and rules are beneficial to the industry. External architectural provisions actually enhance, rather than limit, the creativity of the implementation team.
4.7 Conceptually unified systems can be developed and tested faster.
My understanding:
clarifying the "concept" at the core of requirements and design is an approach that gets to the bottom of things.
Chapter 5 Superfluous
5.2 How can architects successfully influence implementation:
1) Remember that it is the developers who have the creative implementation responsibility; the architects can only make suggestions.
2) Always ready to suggest a way to achieve the specified specification, ready to accept any other possible way.
3) Keep a low profile and calm about the above advice.
4) Be prepared to give up on the proposed improvements.
5) Listen to developers' suggestions for architectural improvements.
My understanding:
This is the working guidelines and principles for architects.
Chapter 7 Why did the Tower of Babylon fail?
7.1 The failure of the Tower of Babylon project was due to a lack of communication, and the result of that communication - organization.
7.2 "As the left hand doesn't know what the right hand is doing, schedule disasters, functional irrationality, and system bugs arise." Due to various assumptions about other people, understanding among team members begins to diverge.
7.16 The goal of team organization is to reduce the amount of communication and collaboration necessary.
7.20 Each subproject has two leadership roles - Product Owner, Technical Lead or Architect. The functions of these two
roles are very different and require different skills.
roles are very different and require different skills.
7.21 Any combination of the two roles can be very effective:
- Product owner and technical lead are the same person.
- The product owner acts as the commander-in-chief, and the technical director acts as his right and left hand. ?? The technical director acts as the commander-in-chief, and the product owner acts as his right and left hand.
Chapter 10 Outline
10.9
The basic responsibility of the project manager is to keep everyone moving in the same direction.
10.10 The main day-to-day job of the project manager is communication, not decision making; documentation enables plans and decisions to be communicated across the team.
My understanding:
Project managers, what are you doing?
Chapter 11 Plan for a Rainy Day
11.3
For most projects, the first developed system is not suitable. It might be too slow, too big, and
difficult to use , or all three.
11.8 The actual needs and perceptions of users will vary as programs are built, tested, and used.
11.9
The ease of grasping and invisibility of a software product causes its builders (especially prone) to be faced
with perpetual changes in requirements.
My understanding: in the
face of changes in demand, be rational and calm.
11.10 Some normal changes in goals (and development strategies) are inevitable, and it's better to prepare for them in advance than to assume they won't happen.
My understanding: it's
okay to plan ahead in moderation, and don't need to think too much.
11.14 It's not just laziness that programmers are reluctant to document their designs. It's more of a hesitation from designers -- to justify their tentative design decisions.
My understanding:
Please understand the work of programmers, don't criticize too much, most of them also want to do their work better.
11.15 Forming a team for a change is more difficult than designing for a change.
My understanding:
To be honest, it is a pity that leaders generally don't see it that way.
11.16 As long as the talents of managers and technicians allow, bosses must pay great attention to their ability development, making managers and technicians interchangeable; in particular, it is hoped that personnel can be freely allocated between technical and managerial roles when.
11.17 There are social obstacles to an efficient organization with two lines of promotion that people must be vigilant and actively fighting against.
11.18 It is easy to establish mutually consistent pay scales for different promotion lines, but establishing equal prestige requires some strong psychological measures: the same office, the same support and priority compensation for technical transfers.
11.19 The formation of a surgical team-like software development team is a complete blow to all aspects of the above problems. This is indeed a long-term and effective solution to the problem of flexible organizational structure.
11.20 Program maintenance is fundamentally different from hardware maintenance; it consists primarily of changes, such as fixes for design flaws, new features, or adjustments due to changes in the usage environment or configuration.
11.21 For a widely used program, the total maintenance cost is usually 40% or more of the development cost. 11.22 Maintenance costs are heavily influenced by the number of users. The more users, the more bugs found.
11.27 The fewer people and interfaces a design implements, the fewer bugs it produces.
11.29 All modifications tend to disrupt the architecture of the system and increase the level of confusion in the system. Even the most skilled software maintenance work only slows down the process of system degradation to irreparable chaos, from which a redesign is necessary. [The real need for many program upgrades, such as performance, etc., especially strikes its internal structural boundaries. Deficiencies arising from the original boundaries often emerge in the future. ]
Chapter 13 Integral Parts
13.2 VAVyssotsky states, "Many and many failures stem entirely from those places where the product is not precisely defined."
My understanding: if it is clear, it will not be too difficult even if it is made; but if it is not clear, it will be difficult to design and implement, and even if the design is implemented, it will be a failure and error.
13.3
Before writing any code, the specification must be submitted to the test team to check in detail the
completeness and clarity of the specification. The developers themselves will not do the work. (Vyssotsky)
My understanding:
It is generally done now, but in many cases the form does not play a practical role.
Chapter 14 Disaster on Xiao Qiang
14.1 "How did the project get delayed by a full year? ...one day at a time."
14.2 Day-to-day lag is more difficult to identify, less preventable and more difficult to remedy .
14.4 Milestones must be specific, specific, measurable events that can be clearly defined.