Preface I once read the Myth of renyue when I was reading. Because I didn’t have much project practice, I didn’t have a deep understanding of the content and problems introduced, so I felt a bit like reading a book from heaven. As a result, I ended it hastily after reading only a few chapters. In these years of work, I was fully responsible for the development and management of a state-owned enterprise project, and also participated in the optimization of the development process of several projects. Gradually, I gained some understanding of project management, and also wanted to learn others’ methodology, so I picked up this classic old book — The Myth of Human Month. The following notes will be mixed with my own thoughts, not all of them are excerpts from the original. Interested students can also read this book on their own.

Tar pits — A new understanding of occupation

The joy that programming provides:

  • The joy of creating things
  • The joy of having a product that is useful to others
  • The charm of assembling parts into an aircraft carrier
  • The joy of continuing to learn
  • Function through thought as a medium that is so flexible and light that it makes work more enjoyable

Reasons for career misery:

  • Strive for perfection. The slightest error, and the system won’t behave as expected
  • Goals are set by others and rely on things beyond their control (e.g. external components/interfaces…)
  • Creative activity is accompanied by tedious repetition of work. Conceptual design is fun, but finding bugs is boring.
  • People expect the project schedule to be linear convergence, but the later the project, the slower the convergence
  • Products face the threat of obsolescence before they are finished

This is programming, a tar pit that many people struggle with, and a creative activity that is both fun and agony [💥 boom]

The myth of man-month — unreasonable schedule

The lack of reasonable schedule is the main reason for the project lag, then why there is unreasonable arrangement?

  • Too optimistic

    • Young programmers assume that “everything will work just fine” and that each task takes only their own time
    • But given the problem of external dependencies, the sequence of tasks, and the cost of assembling them, it is hard to satisfy the “everything will work well” condition

  • The relationship between man and moon is complicated

    • Development costs vary greatly with the number of people and time.
    • Measuring work in months is dangerous because it assumes that people don’t need to talk to each other
    • In a complex task, communication and communication is so much work that adding more people can actually lengthen progress

  • Ignore the importance of testing

    • Because of optimism, software bugs are much more numerous than we expected.
    • Not scheduling enough time for system testing is a disaster……
    • Recommended task scheduling ratios: 1/3 planning, 1/6 coding, 1/4 continuous unit/integration testing, 1/4 final complete system testing
      • Although ideal, the proportion of tasks should be shifted more towards design and testing. In contrast, we now have coding almost the entire life cycle, ignoring the importance of planning and testing, which often leads to the development schedule is out of control: In the early stage, I did not carefully think about the plan and determine the requirements. In the later stage, frequent changes resulted in insufficient time. In order to catch up with the schedule, I compressed the test space.

  • A vague estimate

    • Due to the urgency of the task, the schedule is directly based on customer expectations, ignoring whether the schedule is reasonable
      • All customers/PMS feel that their needs are the most important and urgent right now, but what we (programmers) have to make sure is to produce the highest quality things in a reasonable amount of time, we have to have our own persistence and judgment.
    • Scheduling needs data to support it
    • Until reliable estimates are available, project managers need to stand tall and stick to their estimates
      • Good PM/PMO will greatly increase the life of RD and reduce sudden death rate

  • Error handling behind schedule

    • Do not lag behind the progress, thinking of adding 🔪
    • The project manager should carefully adjust the project, rearrange tasks, or eliminate tasks that fall behind
    • Because there will be upfront costs for newcomers to join, and the cost of interpersonal communication will increase. So adding more people tends not to solve the problem of falling behind.
      • [Department early also have this problem, think pile people can solve the problem, finally we still crazy overtime days…. male silent female tears]
    • Brooks Rule: Adding Manpower to a late software project makes it later

Surgical team – How to build a project team

In the face of large-scale project development, if a small number of capable teams are established, the communication cost is low, but the development cycle is long; If you build a large team, organizational communication is difficult. The book advocates a surgical team structure in which each team performs its own duties to improve team efficiency:

  • technology
    • The architect. Defining features, designing programs, and writing documentation requires talent, experience, and systems knowledge.
    • The assessor. To evaluate the design, a little less experienced than the architect.
    • Experts. Have deep knowledge of certain areas and help solve difficult problems
    • Document maintainer. Unified maintenance of project documents and tools
    • Programmers. Responsible for the implementation of functions
    • The test. Responsible for test cases, build test platform, daily test
  • management
    • The Boss. Have a say in management
    • Secretary. Responsible for assisting Boss to implement the affairs

At the same time, the author advocates that the direction of the system should be determined by the minority, and the practical implementation problem should be solved by the majority. Moreover, it is necessary to professionalize the division of labor for developers to reduce the communication cost of members and improve the efficiency of work. [I think of the division of work in xx, architects write documents and pseudo-code, programmers only need to implement specific modules, become a brick. This way advocated by the author is good for the company, but it is not good for individuals, we need to treat it dialectically.]

When we need to increase the size of the team, we need to adjust the proportion of people, less design decisions, more development implementation people, to maintain the integrity of the whole system design concept. And clearly delineate the boundaries between architecture design and implementation, making work easier to manage and more efficient.

4. Aristocratic despotism — to ensure the integrity of the system concept

  • The integrity of system design requires that the design work must be autocratic
  • The implementation is also creative and can greatly affect the performance of the code

[Agree, design does not need too much democracy, experienced few people to determine the plan is easy to quickly reach consensus on the main body. In addition, students who do concrete implementation can learn top-level design thinking, eat one meal at a time, and then participate in the design after accumulated experience.]

Five. Gild the lily — constraint design

Architect interaction guidelines

  • It is recommended to developers, not dictated. [Need to create space for flexibility of implementers]
  • Be prepared to develop an implementation plan. You must have your own bottom-feeding solution.
  • This advice is kept low key
  • Be ready to abandon insistent suggestions for improvement. 【 Open and humble 】

Keep discipline

When developing the first system, architects tend to lean toward brevity and simplicity. The second system, however, tends to be over-engineered and over-polished, requiring discipline in functional design:

  • Proposals need to be reviewed by multiple people
  • Keep your concept intact and your goals clear
  • Not over-embellished

Six. Implementation

How do you ensure that everyone on the team understands and implements the architect’s decisions?

  • Clear, accurate documentation, while keeping documentation up-to-date
  • A productive meeting
    • Communicate regularly every week
    • Everyone has obligations
    • Seek solutions to problems both internally and externally
    • Formal written documents make decisions
    • The architect has decision-making authority
  • Encourage oncall while keeping a log
  • Strengthen testing to ensure that design decisions are implemented into the system

Why did the Tower of Babylon fail – communication and organization

The Tower of Babylon was man’s second greatest engineering feat and the first recorded complete failure. It had clear goals, enough people, enough materials, enough time and enough technology. Why did it fail? The reason is a lack of communication and organization.

How to communicate in the team:

  • Informal approach. Telephone, face base, quickly solve problems
  • The meeting. Regular regular meetings to synchronize progress and issues
  • Workbook. Large projects for sharing

Organizational structure adjustment

  • The goal of team organization is to reduce the amount of communication and collaboration necessary. From the organizational structure can be from the manpower division, limit the scope of responsibility to achieve.
  • Organizational communication is a network, not a tree
  • The leadership role can be a flexible combination of the product owner and the technical owner, depending on whether it’s resource scheduling or technical design.

Be prepared — Work efficiency

  • Due to external factors, the actual working hours will be longer than expected.
  • Using the right high-level language increases programming productivity by a factor of five

Nine. Cutting feet to fit shoes — project control

The function of the program, memory and so on can not be infinite, must be in the early stage of the scale control

  • Software developers must set scale goals and control scale
  • The architect needs to pay attention to system integrity as individual modules are optimized locally
  • The most important function of a software programming manager is to start from the system as a whole and take a user-oriented attitude.
  • Cultivate new skills of employees to improve system performance [+2 In business iteration, students also need to be specially arranged to learn and investigate new technologies with purpose]
  • The representation of data is fundamental to programming

X. Outlining — documentation

  • Document focus: time, location, people, project content, cost
  • Why have documentation:
    • Written records make differences clear and contradictions prominent
    • As a channel to communicate with others
    • Periodic review
  • The importance of documentation: Documentation encapsulates much of the project manager’s effort to develop and implement plans, allowing plans and decisions to be communicated across the project

Plan for a rainy day — embrace change

The actual needs and feelings of the user will change as the program is built, tested, and used. When goals inevitably change, so do design and technology. We need to change the design as we learn

System design changes

  • Documents and software need calendar and version control

Organizational structure changes

  • Employers need to focus on the competency development of managers and technicians and give them the possibility of exchanging
  • Senior people must be technically and emotionally prepared to be personally involved in development

BugFix is not controllable

  • Software maintenance costs are typically 40%+ of development costs.
  • And because it only considers local effects, not global ones, BugFix introduces new bugs 20-50% of the time. [Inexperienced students often make this mistake. How to cultivate this global awareness is the responsibility of each mentor.]
  • There needs to be an upfront design approach that eliminates or identifies side effects

Iteration is uncontrollable

  • Systems are developed to reduce chaos, so they are inherently metastable. Software maintenance and iteration is to improve the degree of chaos “ha ha ha ha, the system more write more rotten too real, design review and convergence guarantee system concept, complete code specification test, CodeReview, universal tool maintenance guarantee system realize the unity of the style, but every programmer has its own style, the whole system will tend to expand and chaos…
  • In iteration, clear goals and designs are needed to slow down the process of system degradation to unsteady state

Xii. A general tool

  • Develop and maintain common common programming tools to make projects more efficient
  • General-purpose tools require specialized development and maintenance
  • Project managers need to appreciate the importance of common tools

Whole parts — whole systems thinking

How to develop systems, test systems, integrate dependencies, let’s think systematically:

Bug-free design

  • Complete and unambiguous test cases
    • A good test case usually contains all system functions and business scenario description, which can greatly reduce the number of bugs that the system has to find. However, it requires RD to have a deep understanding of business scenario and function implementation, so as to enumerate all operations and expected results in the system.
  • Top-down design
    • From the architecture design, design realization, physical coding realization of three steps, refine each step, separated and refined independent modules
    • Why can top-down design avoid bugs?
      • The structure is clear and the function is easier to describe
      • Module segmentation and independence to avoid system-level bugs
      • The suppression of detail makes it easier to identify structural defects
      • [Dependency inversion]

Building a test platform

  • Type: Single test, integrated, e2E
  • Means: build test platform and control change content

Disaster – How to avoid project delays

When a project gets seriously out of control, it usually comes from termites, not tornadoes. In fact, major disasters are relatively easy to deal with because they are often associated with stress, restructuring, and the emergence of new technologies, and the entire project team can cope with them. But day to day backwardness is hard to identify and make up for. How do we avoid falling behind on daily projects:

  • Define specific, clear, measurable milestones
    • 【 when we project development is easy to set a fuzzy milestone, and at the time of deadLine is also an ostrich, don’t delve into whether reach the standard, so often leave a little tail to the next cycle, cause behind the project progress slowly. Milestone clearly measurable, and at the time of the check to the real measuring result, It is also the openness and clarity that Byte advocates.
  • Stay Aggressive
    • Keep the team positive and progressive, care about the lag of each day, ensure that key tasks do not deviate from the schedule.
  • Feedback problems in time
    • Front-line managers want to solve problems on their own, but bosses want to be kept informed, and differences in thinking can lead to withholding of information
    • How to establish a good problem feedback mechanism in the team:
      • Reduce role conflict. The boss only knows the information, not to overstep the manager to avoid losing authority; The manager reports and proposes solutions in time to reassure the boss.
      • There is a review mechanism to know the truth. Review problems through critical path maps, identifying milestones, and weekly meetings.

【 said too good, because the role needs conflict, causing fluctuation behavior is different, but in order to achieve the purpose of timely feedback problems, both need to optimize their behavior. Managers need to learn to exercise restraint and focus on management rather than a specific implementation. Especially just contact management, total feel subordinate themselves as long as the work 1 week 1 day, To write code. It’s not delegate will not only lead to subordinate ability can’t improve, reduce the morale of the team, but also makes himself can’t focus on management. Practitioners need to change the idea, timely feedback problem is to let managers to better coordination work content and time, but also optimize the mechanism of task again, Don’t see it as a denial of your abilities, and include solutions to give your boss confidence.

15. The other side — how to write good documents

We all know the importance of documentation, but how to write good documentation?

  • User documentation
    • purpose
    • Environment and Scope
    • function
    • Instructions and Options
    • performance
    • The test case
    • Modify the record
  • The flow chart
  • Self-documenting. That is, the document into the source code, more convenient and timely
    • Improved readability of source code
    • annotation
    • Standardize the project structure and naming

[Self-documentation is high, programmers tend to look at the code, this time comments and naming is very important…. please do not overconfidence in their own code readability, in order to avoid subsequent maintenance staff lose too much hair, add some comments]

No silver bullet – primary and secondary missions

In all software development, the primary task is to build the complex conceptual structures that make up abstract software entities. The secondary task is to express these abstract entities in a programming language and map them to a machine language. When doing the underlying tasks, note:

  • Do careful market research and avoid building wheels
  • Use rapid prototyping as part of an iteration plan to validate and capture requirements
  • Update software organically and iteratively
  • Constantly select and train concept designers [I have to say, the talent who can create new fields is the treasure of every team]

Is there a silver bullet?

There is no silver bullet to solve the fundamental problem. There is no answer. Software project management needs to be done on a case-by-case basis, and there is no single method that can achieve an order of magnitude of efficiency improvement for all projects. But standardized methods and systems can greatly increase productivity. At the same time, the solution is not achieved overnight, but gradually acquired iteratively. Day arch a pawn, work does not donate tang.

Root cause of difficulty

  • The complexity of the
    • The expansion of software entities brings about nonlinear complexity growth
    • Complexity can lead to technical difficulties and management problems
  • consistency
    • Software complexity is introduced for consistency and compatibility
  • variability
    • The low modification cost and changing requirement scenarios will result in the constant pressure of software change
  • invisibility
    • Software does not have the physical characteristics of space, which limits the personal design process and blocks the communication of ideas

How to solve the underlying problem

  • Buy software
    • The most radical solution to building software is not to develop software.
    • Because of multi-user cost sharing, the cost of buying software is lower than developing it
  • Need refinement and rapid prototyping
    • The customer does not know what the requirements are, and the PM/RD needs to extract the deepest requirements. [Do not trust the idea of the customer. I met a customer who asked me to modify it repeatedly before, and after in-depth understanding, I could get a common function.]
    • Rapid prototyping to simulate pages, clarify actual conceptual structures, and align with customers.
  • Incremental development
    • Design and develop the trunk first, then populate the subsystems
    • You need top-down design.
  • Excellent designers
    • Develop and acquire contacts with designers

There is no silver bullet

Secondary issues don’t take up 90% of development time or increase productivity by an order of magnitude, so address the root of development. [Our current engineering approach feels like we are still solving secondary problems]

Fix the root problem

  • Complexity is hierarchical
    • Most of the time system complexity comes from the fact that we don’t have proper abstractions and layers
    • The method of logical processing needs atomicity to facilitate subsequent reuse
    • Consider the hierarchical and incremental design of the system [think of the pluggable design of some large components]
  • invisibility
    • Many of the conceptual elements of the software are topological in nature and can be expressed and improved using visualized graphics/Spaces.
    • This visualization may improve the quality of developers’ thinking and exploration in the future to solve some fundamental problems
    • But because software elements do not exist in three dimensions, there is no simple mapping from conceptual design to graphics

In the end, there is no silver bullet that will completely solve the underlying problem. [The complexity and variability of software determines that there is no silver bullet]

conclusion

The description in the book is a little scattered, so I sorted out what I learned according to the project process:

  • Requirements research and validation
    • Research early and avoid building wheels
    • To meet the needs of the situation, priority to purchase existing products
    • Rapid prototyping validation requirements
    • You need to control the scale of project requirements and functions
  • To form a team
    • Hire good people. A good programmer can be 10 times more productive than a bad programmer
    • Build a surgical team, each with its own responsibilities
    • A few people think about the direction of the system, and a lot of people solve the actual implementation problems
    • Professional division of labor, reduce cooperation costs
  • Project scheduling and progress tracking
    • Evaluate your schedule based on experience and past data and don’t be overly optimistic
    • Pay attention to the structure of team members, face up to the concept of man-month, do not blindly add people
    • Arrange the time of each link of the project scientifically, and reserve sufficient time for system design and test
    • Set clear milestones and be honest about how you measure your results
    • Arrange weekly and monthly meetings to synchronize progress and problems regularly
    • Keep the team motivated and ahead of schedule
    • Feedback problems in time, adjust the plan
  • The system design
    • Adopt top-down design to improve system expansibility and avoid bugs
    • A few experienced people are responsible for system design to ensure conceptual integrity of the system
    • The designer should have a concrete implementation plan
    • Plan review is required to control system size and avoid over-design
    • Design changes are inevitable. Manage documentation and releases
  • Document the precipitation
    • Record analysis and contradiction to facilitate decision making
    • Periodic review
    • Record detailed functions and designs for easy sharing and communication
    • Focus on self-documentation
  • Communication and cooperation
    • Encourage networking, not trees
    • Use informal approaches, meetings, workbooks, etc., to synchronize progress and issues
    • Reduce communication costs through some means (manpower division, limited scope of responsibility)
  • To improve efficiency
    • Adopt good system design
    • Attaches great importance to the document
    • General Maintenance Tools
    • Building a test platform
  • Dealing with Unknown changes
    • Embrace change and prepare for changes in system design and organizational structure
    • Focus on early system design and test cases to greatly reduce system bugs
    • Clear system objectives, maintain design integrity, reduce the increase rate of system entropy,

Project management is mainly concerned about the people and the management, the whole book mostly in software engineering management, less involved in technical problems, mainly comes from a belief that for the success of the project, the project’s quality, personnel organization and management is better than using the adopted technology of the tool or method of important factor. And the man-moon myth also holds the view that there is no silver bullet, there is no limit to how we deal with problems and the space of imagination. Project management is for software development services, we in the management of norms and standards is not the end, but the means. The man-month myth just happens to provide some enlightening perspectives that give us more thinking and imagination about project management.