''The Mythical Man-Month: Essays on Software Engineering'' is a book on
software engineering
Software engineering is a systematic engineering approach to software development.
A software engineer is a person who applies the principles of software engineering to design, develop, maintain, test, and evaluate computer software. The term '' ...
and
project management
Project management is the process of leading the work of a team to achieve all project goals within the given constraints. This information is usually described in project documentation, created at the beginning of the development process. Th ...
by
Fred Brooks
Frederick Phillips Brooks Jr. (April 19, 1931 – November 17, 2022) was an American computer architect, software engineer, and computer scientist, best known for managing the development of IBM's System/360 family of computers and the O ...
first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. This idea is known as
Brooks's law
Brooks' law is an observation about software project management according to which adding manpower to software project that is behind schedule delays it even longer.Frederick P. Brooks, Jr. '' The Mythical Man-Month''. 1995 975 Addison-Wesley. It ...
, and is presented along with the
second-system effect
The second-system effect or second-system syndrome is the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.
The phrase was first used by Fred ...
and advocacy of
prototyping
A prototype is an early sample, model, or release of a product built to test a concept or process. It is a term used in a variety of contexts, including semantics, design, electronics, and software programming. A prototype is generally used to ...
.
Brooks's observations are based on his experiences at
IBM while managing the development of
OS/360
OS/360, officially known as IBM System/360 Operating System, is a discontinued batch processing operating system developed by IBM for their then-new System/360 mainframe computer, announced in 1964; it was influenced by the earlier IBSYS/IBJOB ...
. He had added more
programmer
A computer programmer, sometimes referred to as a software developer, a software engineer, a programmer or a coder, is a person who creates computer programs — often for larger computer software.
A programmer is someone who writes/creates ...
s to a project falling behind schedule, a decision that he would later conclude had, counter-intuitively, delayed the project even further. He also made the mistake of asserting that one project—involved in writing an
ALGOL
ALGOL (; short for "Algorithmic Language") is a family of imperative computer programming languages originally developed in 1958. ALGOL heavily influenced many other languages and was the standard method for algorithm description used by the ...
compiler
In computing, a compiler is a computer program that translates computer code written in one programming language (the ''source'' language) into another language (the ''target'' language). The name "compiler" is primarily used for programs that ...
—would require six months, regardless of the number of workers involved (it required longer). The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it".
Editions
The work was first published in 1975 (),
reprinted with corrections in 1982, and republished in an anniversary edition with four extra chapters in 1995 (), including a reprint of the essay "
No Silver Bullet
"No Silver Bullet—Essence and Accident in Software Engineering" is a widely discussed paper on software engineering written by Turing Award winner Fred Brooks in 1986. "No Silver Bullet—Essence and Accident in Software Engineering" Brooks argu ...
" with commentary by the author.
Ideas presented
The mythical man-month
Brooks discusses several causes of scheduling failures. The most enduring is his discussion of
Brooks's law
Brooks' law is an observation about software project management according to which adding manpower to software project that is behind schedule delays it even longer.Frederick P. Brooks, Jr. '' The Mythical Man-Month''. 1995 975 Addison-Wesley. It ...
:
''Adding manpower to a late software project makes it later''.
Man-month is a hypothetical unit of work representing the work done by one person in one month; Brooks's law says that the possibility of measuring useful work in man-months is a myth, and is hence the centerpiece of the book.
Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.
Therefore, assigning more programmers to a project running behind schedule will make it even later. This is because the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever-increasing quantity of the calendar time available. When ''n'' people have to communicate among themselves, as ''n'' increases, their output decreases and when it becomes negative the project is delayed further with every person added.
* Group intercommunication formula: ''n''(''n'' − 1)/2.
* Example: 50 developers give 50 × (50 – 1)/2 = 1,225 channels of communication.
No silver bullet
Brooks added the chapter "No Silver Bullet—Essence and Accidents in Software Engineering" and further reflections on it in the chapter "'No Silver Bullet' Refired" to the anniversary edition of ''The Mythical Man-Month''.
Brooks insists that there is no one
silver bullet
In folklore, a bullet cast from silver is often one of the few weapons that are effective against a werewolf or witch. The term ''silver bullet'' is also a metaphor for a simple, seemingly magical, solution to a difficult problem: for example, pe ...
: "there is no single development, in either technology or management technique, which by itself promises even one
order of magnitude
An order of magnitude is an approximation of the logarithm of a value relative to some contextually understood reference value, usually 10, interpreted as the base of the logarithm and the representative of values of magnitude one. Logarithmic dis ...
enfoldimprovement within a decade in productivity, in reliability, in simplicity."
The argument relies on the distinction between accidental complexity and essential complexity, similar to the way
Amdahl's law
In computer architecture, Amdahl's law (or Amdahl's argument) is a formula which gives the theoretical speedup in latency of the execution of a task at fixed workload that can be expected of a system whose resources are improved. It states that ...
relies on the distinction between "parallelizable" and "strictly serial".
The second-system effect
The
second-system effect
The second-system effect or second-system syndrome is the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.
The phrase was first used by Fred ...
proposes that, when an architect designs a second system, it is the most dangerous system they will ever design, because they will tend to incorporate all of the additions they originally did not add to the first system due to inherent time constraints. Thus, when embarking on a second system, an engineer should be mindful that they are susceptible to over-engineering it.
The tendency towards irreducible number of errors
The author makes the observation that in a suitably complex system there is a certain irreducible number of errors. Any attempt to fix observed errors tends to result in the introduction of other errors.
Progress tracking
Brooks wrote "Question: How does a large software project get to be one year late? Answer: One day at a time!" Incremental slippages on many fronts eventually accumulate to produce a large overall delay. Continued attention to meeting small individual milestones is required at each level of management.
Conceptual integrity
To make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. A single chief architect (or a small number of architects), acting on the user's behalf, decides what goes in the system and what stays out. The architect or team of architects should develop an idea of what the system should do and make sure that this vision is understood by the rest of the team. A novel idea by someone may not be included if it does not fit seamlessly with the overall system design. In fact, to ensure a user-friendly system, a system may deliberately provide ''fewer'' features than it is capable of. The point being, if a system is too complicated to use, many features will go unused because no one has time to learn them.
The manual
The chief architect produces a manual of system specifications. It should describe the external specifications of the system in detail, that is everything that the user sees. The manual should be altered as feedback comes in from the implementation teams and the users.
The pilot system
When designing a new kind of system, a team ''will'' design a throw-away system (whether it intends to or not). This system acts as a "pilot plan" that reveals techniques that will subsequently cause a complete redesign of the system. This second, ''smarter'' system should be the one delivered to the customer, since delivery of the pilot system would cause nothing but agony to the customer, and possibly ruin the system's reputation and maybe even the company.
Formal documents
Every project manager should create a small core set of formal documents defining the project objectives, how they are to be achieved, who is going to achieve them, when they are going to be achieved, and how much they are going to cost. These documents may also reveal inconsistencies that are otherwise hard to see.
Project estimation
When estimating project times, it should be remembered that
programming product Software as a product (SaaP, also programming product, software product) is a product, software, which is made to be sold to users, and users pay for licence which allows them to use it, in contrast to SaaS, where users buy subscription and where t ...
s (which can be sold to paying customers) and programming systems are both three times as hard to write as simple independent in-house programs.
The Mythical Man-Month
Figure 1.1, Page 13 It should be kept in mind how much of the work week will actually be spent on technical issues, as opposed to administrative or other non-technical tasks, such as meetings, and especially "stand-up" or "all-hands" meetings.
Communication
To avoid disaster, all the teams working on a project should remain in contact with each other in as many ways as possible (e-mail, phone, meetings, memos, etc.). Instead of assuming something, implementers should ask the architect(s) to clarify their intent on a feature they are implementing, before proceeding with an assumption that might very well be completely incorrect. The architect(s) are responsible for formulating a group picture of the project and communicating it to others.
The surgical team
Much as a surgical team during surgery is led by one surgeon performing the most critical work, while directing the team to assist with less critical parts, it seems reasonable to have a "good" programmer develop critical system components while the rest of a team provides what is needed at the right time. Additionally, Brooks muses that "good" programmers are generally five to ten times as productive as mediocre ones.
Code freeze and system versioning
Software is invisible. Therefore, many things only become apparent once a certain amount of work has been done on a new system, allowing a user to experience it. This experience will yield insights, which will change a user's needs or the perception of the user's needs. The system should, therefore, be changed to fulfill the changed requirements of the user. This can only occur up to a certain point, otherwise the system may never be completed. At a certain date, no more changes should be allowed to the system and the code should be frozen. All requests for changes should be delayed until the ''next'' version of the system.
Specialized tools
Instead of every programmer having their own special set of tools, each team should have a designated tool-maker who may create tools that are highly customized for the job that team is doing (e.g. a code generator tool that creates code based on a specification). In addition, system-wide tools should be built by a common tools team, overseen by the project manager.
Lowering software development costs
There are two techniques for lowering software development costs that Brooks writes about:
* Implementers may be hired only after the architecture of the system has been completed (a step that may take several months, during which time prematurely hired implementers may have nothing to do).
* Another technique Brooks mentions is not to develop software at all, but simply to buy it "off the shelf
Off-the-shelf may refer to:
* Commercial off-the-shelf, a phrase in computing and industrial supply terminology
* Government off-the-shelf
* Ready-to-wear
* Shelf corporation, a type of company
* Off the Shelf Festival, a festival of writing and ...
" when possible.
See also
*Anti-pattern
An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by computer programmer An ...
*Code refactoring
In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the '' factoring''—without changing its external behavior. Refactoring is intended to improve the design, structur ...
*'' Peopleware: Productive Projects and Teams''
*Software development process
In software engineering, a software development process is a process of dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design, product management. It is also known as a software devel ...
*Hofstadter%27s law
Hofstadter's law is a self-referential adage, coined by Douglas Hofstadter in his book '' Gödel, Escher, Bach: An Eternal Golden Braid'' (1979) to describe the widely experienced difficulty of accurately estimating the time it will take to complet ...
Bibliography
*
*
*
References
External links
Frederick P. Brooks, Jr. Homepage
A review by Hector Correa on chapters "The Mythical Man-Month" and "No Silver Bullet – Essence and Accident"
Selected TEXT from ''The Mythical Man-Month''
{{DEFAULTSORT:Mythical Man-Month, The
1975 non-fiction books
Software development books
Software project management
Addison-Wesley books