From the myth of the man month
The Mythical Man-Month: Essays on Software Engineering ( German The Mythical Man-Month: Essays on Software Engineering ) is a book of the US computer scientist Fred Brooks on software engineering and project management . His core message, described by the author himself (albeit "incredibly simplistic") as Brooks' law , is:
"Adding manpower to a late software project makes it later."
"The use of additional manpower for software projects that have already been delayed only delays them even more."
Brooks' experience is based on his observations at IBM as head of development for OS / 360 . At that time, for example, he had assigned more programmers to a sub-project that was delayed ; he later concluded that, contrary to all intuition, this decision made the delay worse. Also, his claim proved false, some project (writing an Algol - compiler ) will take six months, regardless of the number of employees; actually it took longer. Given the propensity of project managers to make such mistakes, Brooks scoffed that his book was called the "Software Engineering Bible" because:
"Everybody quotes it, some people read it, and a few people go by it."
"Everyone cites it, some read it, and some people follow it."
The book is widely regarded as a classic on the human factors in software engineering.
The English-language original edition appeared in 1975, a corrected new edition in 1982, the German translation in 1991. In 1995 an anniversary edition with four additional chapters as well as the essay No Silver Bullet: Essence and Accident in Software Engineering and a commentary by the author, German in 2003, was published.
Ideas and concepts
The "Man Month Myth"
Brooks discusses various causes for planning failures. Most of the space is taken up by his discussion of Brooks' Law : " Adding extra manpower to software projects that have already been delayed only delays them further." Man-month is a hypothetical unit of measure for the average amount of work a person can do in a month ; Brooks' Law states that measuring useful work in man-months is a myth, and so it is the essence of the book.
Complex programming projects cannot be completely divided into separate tasks that can be carried out without communication between the users and without a complex set of relationships between tasks and users.
Software projects that have already been delayed are therefore only further delayed by the use of additional workers. This is due to the fact that the training period and the increased communication needs of the new programmers devour an ever increasing proportion of the available project time. If n people need to communicate with each other, their output decreases with increasing n , and as soon as it becomes negative, the project is delayed with each additional person deployed.
- Number of communication relationships: n ( n - 1) / 2
- Example: 50 developers result in 50 · (50 - 1) / 2 = 1225 communication channels.
No "silver balls"
Brooks added the essay No Silver Bullet - Essence and Accidents of Software Engineering and other considerations under the title “No Silver Bullet” Refired to the anniversary edition of his book . In mythology , a bullet cast from silver is often the only effective weapon against werewolves , witches and other monsters ; Brooks postulates that there is no such "silver bullet":
"There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."
"There is not a single development, either technological or in management techniques , that on its own could promise to guarantee at least an order of magnitude [ten times] in improvements in productivity, reliability, or simplicity over the course of ten years ."
His argument is based on the distinction between random and essential complexity, similar to how Amdahl's law distinguishes between “strictly serial” and “parallelizable” processes.
The problem of the second system
The term second-system effect , coined by Brooks, postulates that the second version of a system will be by far the most dangerous, because architects tended to include here all the extensions that fell victim to the inevitable lack of time in the first version. The author names various IBM products to support his thesis, including a. the stretch computer and OS / 360 , and gives advice on how to avoid it.
The number of errors that cannot be further reduced
The author makes the observation that any sufficiently complex system always has a minimum number of errors. Every attempt to eliminate recognized errors results in new errors.
Appointment management
Brooks writes: “Question: How is it that a large software project is delayed by a year? Answer: By a day each time! ”Slight delays on many fronts add up to a large overall delay. On the other hand, only a constant review of the individual milestones at all management levels helps .
Conceptual integrity
The prerequisite for a user-friendly system is the integrity of its concept, which can only be achieved by separating architecture and implementation. On behalf of and on behalf of the user, a chief architect (or a small number of architects) decides what goes into the system and what stays outside. The chief architect should come up with an idea of what the system should do and ensure that this vision is understood by the rest of the development team. Any new suggestions from individuals will not be included if they do not fit seamlessly into the overall design.
To ensure a user-friendly system, a system may intentionally have fewer features than would be possible. Because if it is too complicated to use, many of its functions will go unused because nobody has the time to learn how to use them.
The manual"
The chief architect prepares a system specification manual that precisely describes the external characteristics of the system, i. H. everything the user sees. It should be updated depending on the feedback from implementation teams and users.
The pilot system for the trash can
When a team is developing a new system that is there - whether intentional or not - first create a "disposable" system. This system serves as a “test facility” in order to immediately uncover those procedures that would later require a complete redesign of the system. Only this second, smarter system should be delivered to the customer, because the pilot system would cause nothing but agony for the customer and possibly ruin the reputation of the system or even the whole company.
Formal documents
Each project leader should produce a small set of documents that define the project objectives, how , by whom and when they will be achieved, and what it will cost. These documents can also reveal inconsistencies that would otherwise be difficult to detect.
Estimation of the time required
When estimating project times , one should bear in mind that both program products (for paying customers) and program systems are at least three times as laborious to write as simple, stand-alone in-house programs. , P. 5 Fig. 1.1 One should take into account what percentage of working time is actually spent on technical issues, compared to administrative or other non-technical tasks such as (especially overall ) team meetings.
communication
To avoid mischief, all teams working on a project should stay in contact with each other in as diverse a way as possible - email, phone, meetings, memos, etc. Instead of assuming something about a function to be implemented and continuing to work with a possibly incorrect assumption, the Implementers ask the architect (or architects) to explain the intentions of this feature . The architect is responsible for formulating an overall picture of the project and communicating it to the others.
The medical team
Similar to the way a medical team is led by a chief physician who operates himself and receives the best possible support from his team, it makes sense to have critical system components developed by a "good" programmer while the rest of the team delivers as required. Brooks also muses that “good” programmers are usually five to ten times as productive as mediocre ones.
Code freeze and version management
Software is invisible. Therefore, with a new system, some things are only noticeable when a certain development effort has been made that allows the user to experience the system himself. This experience can lead to insights that change the user's needs (or their perception). Then the system should be changed accordingly to meet the changed requirements. However, this can only happen up to a certain point, otherwise the system may never finish. After a certain date, code changes to the system should no longer be permitted; the code is "frozen" and all further change requests are postponed until the next system version.
Special tools
Instead of each individual programmer using their own set of special tools, each team should have a named “toolmaker” who creates tools that are precisely tailored to the team's tasks, e.g. B. a code generator that generates code according to a specification. In addition, tools used throughout the system should be created by a central tool team under the supervision of the project manager.
Reduction of software development costs
Brooks describes two kinds of techniques to reduce software development costs:
- Implementers are only engaged after the system architecture is complete - a point that can take several months before previously hired implementers have nothing to do.
- Alternatively, Brooks mentions not developing software at all , but simply using standard software whenever possible.
See also
Web links
Individual evidence
- ↑ a b c d Frederick P. Brooks, Jr .: The Mythical Man-Month . Essays on Software Engineering. Addison-Wesley, 1975, ISBN 978-0-201-00650-6 (American English, archive.org ).
- ↑ a b Frederick P. Brooks: From the myth of the man month . Essays on software engineering. Addison Wesley, 1991, ISBN 978-3-925118-09-8 (American English: The Mythical Man-Month . Translated by Arne Schäpers, Armin Hopp).
- ^ Daniel Roth: Quoted Often, Followed Rarely . In: CNN , December 12, 2005. Retrieved October 23, 2010.
- ↑ Jess Johnson: The Top 9½ In a Hacker's Bookshelf . Retrieved October 23, 2010.
- ↑ Frederick P. Brooks, Jr .: The Mythical Man-Month . Essays on Software Engineering. Addison-Wesley, 1995, ISBN 978-0-201-83595-3 (American English).
- ↑ a b Frederick P. Brooks: From the myth of the man month . Essays on software engineering. MITP, 2003, ISBN 978-3-8266-1355-5 (American English: The Mythical Man-Month . 1995. Translated by Arne Schäpers).
- ↑ a b Hector Correa: The Mythical Man-Month ( en ) In: All Blog Posts . June 28, 2007. Retrieved January 8, 2017.
- ↑ Frederick. P., Jr. Brooks: No Silver Bullet - Essence and Accident in Software Engineering . (PDF) In: Computer . 20, No. 4, 1987, p. 10. doi : 10.1109 / MC.1987.1663532 . Retrieved January 19, 2017.