Actual man month
We in Wrike have a tradition to share with the team thoughts about the books that have been read. We have long thought that it would be nice to extend this initiative to our blog on Habrahabr, and here we have a good case - Frederick Brooks ’s Mythical Man-Month book.
The book can be called a classic of folklore development, rather than a real guide to building a workflow. It reflects the problems that Brooks encountered in organizing work on the creation of the OS / 360 operating system, and his approaches to solving them. The result was far from ideal, as Brooks himself points out. His goal was not to teach how to properly, but to raise the problems that need to be solved. It is curious to understand what has changed in the design since the 1960s.
Photo from IBM archive
Before talking about the book itself, you need to understand the context. What actually was the project OS / 360, for what purpose it was developed and in what conditions.
')
System / 360 history
In the early 1960s, IBM was the absolute leader in the computer market. Its share was 75%. However, the prospects were becoming less bright. Absolutely all IBM systems were incompatible with each other. Series 1401, 1620, 7070, etc. were completely isolated. If you want to switch from 1401 to 1620 - buy not only a new processor, but also all the peripherals. Soft, too, will have to rewrite.
Expensive pleasure for the client, not everyone will decide on this. And for IBM itself, the situation looked bad. We had to support the production of outdated equipment, maintain a staff of specialists who can configure it, train engineers on the client side with outdated technologies. At the same time, the transition from one system to another required complete retraining. The situation was aggravated by the fact that many of the systems were highly specialized, for example, dispatching systems.
And so, in January 1961, the 29-year-old Brooks presents the draft of the next 8000 series. Of course, the new system is better than the previous ones in everything, but in one it is the same with them. This is another completely unique complex, the transition to which will cost millions of customers, as well as its support for IBM itself. It is clear that this is a dead end. The project is closed, and Brooks is offered to lead the group to develop a completely new system. But what no one knew. One thing was clear - in the future, the new system should provide backward compatibility at both the hardware and software levels, as well as be a general-purpose system suitable for banks, military and scientists.
A group of 25 people was formed, headed by Brooks, who was engaged in developing a plan for the new system. The process was moving slowly, and in order to speed it up, the management decided to move the working group to a hotel in the suburbs of New York with an ultimatum that the team would not leave there until it came to a common decision. And they came. And this decision was given a green light.
The entire hardware and software complex was called System / 360, and the operating system was OS / 360. Ironically, it was decided to solve backward compatibility problems by eliminating compatibility with previous systems.
The development of the system took significantly more than the planned time frame, its cost was not $ 625 million, but $ 5.25 billion - a little less than the Appollo program with its rockets, astronauts and landing on the moon for the same 1965 year. The risk of bankruptcy for IBM was quite real, but everything worked out. The announcement of the system took place on April 7, 1964, and the first products were released in mid-1965 . The success was enormous. The principle of interchangeability of components laid down in the framework of this system is observed to this day. By the way, it was after System / 360 that the standard byte size was 8 bits.
Brooks's main allegations
From the preface to the second edition: “This book is a belated answer to questions about the difficulties of developing programs (“ belated ”in 1975! - author's note). Over the next decade, there will be no programming methods, the use of which will allow an order of magnitude increase in the productivity of development, all other things being equal. "
Among the main allegations of Brooks, which have become commonplace, include the following:
This is not all thoughts given in the book, but they seem to be the most important. It would be inappropriate to analyze all 214 statements, especially since many of them are quite obvious. For example, with the fact that it is best to have a small active team - you can not argue.
However, changes in the relevance of these statements reflect changes in the software development industry.
The first and second systems 50 years later
The software product becomes obsolete before its completion, the architecture of the second system will turn out bad, and the first one will have to be thrown out, because it will not satisfy the needs of users. It turns out that something sensible can come out only from the third time? Not. In a sense, Brooks is right, but we learned how to deal with it.
The software product will inevitably become obsolete before its completion , if you develop it for five years. That is what happened with System / 360. All modern approaches to development imply a quick release of the first version, albeit with a minimal, but practically useful set of functions. The same concept of user stories is primarily aimed at choosing a small but integral part of the entire set of customer needs for implementation. Then the product can be released quickly and get feedback.
The first version will have to throw out if you do it blindly. But if the first version is not too bloated, and in the process of its development the wishes of real users will be taken into account, everything can turn out quite well. With the beginning of use, many comments will inevitably appear, but if you listen to feedback before the first release, the chance of a complete failure is significantly reduced. Correct comments is not a problem, just to use the product.
The architecture of the second system will turn out bad . Project System / 360 Brooks considers it the second system. Specialized projects that IBM developed earlier turned out to be quite good, but from 360 they decided to do everything correctly.
Architectural decisions are not made from scratch, they are the answer to the problems. If the system develops evolutionarily, these problems are real and quite tangible. They can be disassembled, understood, and find a solution. Starting from scratch, it is very easy to miss what is really important for users - no one can foresee everything. However, it is nevertheless dangerous to fall into the trap of solving imaginary problems that exist only in the head of an architect / analyst, but have no relation to reality.
The problem of the second system as a whole exists, but we have learned how to avoid it without making the second system . Instead, the first released product develops evolutionarily and iteratively. Sometimes refactoring, migration, and backward compatibility are expensive, but it’s not such a big price to keep in touch with reality.
Ultimately, development sped up not technological development, but shortening the development cycle and getting quick feedback.
Mythical and actual man-month
Regarding the fact that when developing software projects, it is impossible to manipulate the estimates in man-months, Brooks is a little cunning. In fact, this can not be done in any project .
Planning the timing and resources of a project is a simple matter. If you know all the tasks, the dependencies between them, estimates of terms and necessary resources, then everything is quite simple. Only the lazy will not cope with the creation of a plan in such conditions. But even in this case, you can not add people endlessly to speed up the project. There is always a critical path that determines the minimum possible time, regardless of the amount of resources. For more on this, see "Project Management in the USSR (1976)" and "Critical Chain" .
Unfortunately, the conditions necessary for planning are not always fulfilled. In this case, make a correct plan is impossible . Even estimates of the timing of individual tasks are always obtained from practical experience . But what if there is no such experience? Tying shoelaces is a matter of minutes, or rather, 5-7 seconds. Tying shoelaces every day, we can from our experience accurately estimate how long it will take us to do this work tomorrow. But try to predict how long it will take for you to tie your shoelaces with one hand . Will your assessments match the actual experience? Curious experiment. Read more - Robert C. Martin "Effective Estimation (or: How not to Lie)" .
We are very bad at planning what we have never done, any new initiatives, not just software development. It was in this situation that Brooks found himself when he was asked to draw up a project plan, as well as an assessment of the timing and cost of developing System / 360.
Even if you lock up all the key professionals in the hotel, they still will not be able to make an exact plan for a large software project. Unfortunately, IBM management put Brooks in a hopeless situation, which probably prompted him to write a book later.
However, short-term planning is quite realistic. If you plan an iteration for 2-4 weeks, you can do it quite accurately. Over time, the skill of decomposing large tasks into smaller ones is acquired, and smaller tasks are easier to evaluate. In addition, constantly working in one direction, a person accumulates expertise. The tasks that three months ago seemed completely new, so that they could be evaluated only with a finger to the sky, turn out to be quite similar to the recent ones. Hence, the estimates of their dates will be similar.
Of course, it is impossible to evaluate software projects in person months, but it is quite possible to plan the work for the next month. And this plan for the next month will not be mythical, but quite reasonable, factual .
What did Brooks miss
- Mr. Brooks, you said that you will need two years and $ 625 million for the project, two and a half years have passed, you have twice exceeded the budget, but there are no results. Mr. Brooks, do you understand that the success of the entire company depends on the early completion of your project? We give you another $ 2 billion and hire you an additional 500 people.
“Mr. Brooks, your task is to complete all the necessary work during the next year.”
Of course, we don’t know if Brooks actually said this, but this could well have happened.
Brooks explains in detail and in detail why adding resources at the initiative of management cannot accelerate a protracted project. It is necessary to reschedule all the work, to spend time on introducing new specialists in the course of business, instill in them the rules of development, and so on. In all of this, Brooks is certainly right, but that's not the point.
The real problem of Brooks is not that it took four years to complete his project, and not only that the budget amounted to $ 5 billion, but that he was unable to plan precisely in advance neither the time frame nor the budget. In fact, he was wrong 10 times. Of course, Brooks is looking for a way to speed development in the same 10 times, but this is not a solution.
No one in the place of Brooks would have been able to give a more accurate, informed assessment of the project. Of course, someone else could say three years and two billion dollars, in this case the error would be less. But such a “more accurate estimate” would be the result of a successful guess rather than a rational prediction.
The main conflict of the book is that from a business point of view, you need to know exactly how long the project will take and how many resources it will take, and Brooks was forced to answer these questions. In reality, everything turned out quite differently as planned, for which Brooks feels a personal responsibility. He promised, he did everything he could, he did not succeed. But you must admit, it is not quite honest to demand from a person to make a promise that he most likely will not be able to fulfill.
Everything could turn out differently if, at the beginning of the project, Brooks insisted that the project budget could be from $ 1 to $ 6 billion, and the duration from 3 to 7 years, and it is impossible to give more accurate estimates. And IBM management, in turn, recognized these estimates.
Perhaps it would be better to plan the company's budget, knowing the possible risks of delaying the project and increasing its budget. This is better than running into a problem when the money has run out. Perhaps there would be a way to change the approach to promotion and sales, in such a way as to make it possible to minimize the scale of the project, make it less uncertain, and therefore less risky. Perhaps something else could be done that goes beyond the competence of the engineering department, which would help the success of the project. But at that time such a fundamental change in the approach to work was beyond the limits of what is permitted. There were very different times, the 1960s.
The book can be called a classic of folklore development, rather than a real guide to building a workflow. It reflects the problems that Brooks encountered in organizing work on the creation of the OS / 360 operating system, and his approaches to solving them. The result was far from ideal, as Brooks himself points out. His goal was not to teach how to properly, but to raise the problems that need to be solved. It is curious to understand what has changed in the design since the 1960s.
Photo from IBM archive
Before talking about the book itself, you need to understand the context. What actually was the project OS / 360, for what purpose it was developed and in what conditions.
')
System / 360 history
In the early 1960s, IBM was the absolute leader in the computer market. Its share was 75%. However, the prospects were becoming less bright. Absolutely all IBM systems were incompatible with each other. Series 1401, 1620, 7070, etc. were completely isolated. If you want to switch from 1401 to 1620 - buy not only a new processor, but also all the peripherals. Soft, too, will have to rewrite.
Expensive pleasure for the client, not everyone will decide on this. And for IBM itself, the situation looked bad. We had to support the production of outdated equipment, maintain a staff of specialists who can configure it, train engineers on the client side with outdated technologies. At the same time, the transition from one system to another required complete retraining. The situation was aggravated by the fact that many of the systems were highly specialized, for example, dispatching systems.
And so, in January 1961, the 29-year-old Brooks presents the draft of the next 8000 series. Of course, the new system is better than the previous ones in everything, but in one it is the same with them. This is another completely unique complex, the transition to which will cost millions of customers, as well as its support for IBM itself. It is clear that this is a dead end. The project is closed, and Brooks is offered to lead the group to develop a completely new system. But what no one knew. One thing was clear - in the future, the new system should provide backward compatibility at both the hardware and software levels, as well as be a general-purpose system suitable for banks, military and scientists.
A group of 25 people was formed, headed by Brooks, who was engaged in developing a plan for the new system. The process was moving slowly, and in order to speed it up, the management decided to move the working group to a hotel in the suburbs of New York with an ultimatum that the team would not leave there until it came to a common decision. And they came. And this decision was given a green light.
The entire hardware and software complex was called System / 360, and the operating system was OS / 360. Ironically, it was decided to solve backward compatibility problems by eliminating compatibility with previous systems.
The development of the system took significantly more than the planned time frame, its cost was not $ 625 million, but $ 5.25 billion - a little less than the Appollo program with its rockets, astronauts and landing on the moon for the same 1965 year. The risk of bankruptcy for IBM was quite real, but everything worked out. The announcement of the system took place on April 7, 1964, and the first products were released in mid-1965 . The success was enormous. The principle of interchangeability of components laid down in the framework of this system is observed to this day. By the way, it was after System / 360 that the standard byte size was 8 bits.
Brooks's main allegations
From the preface to the second edition: “This book is a belated answer to questions about the difficulties of developing programs (“ belated ”in 1975! - author's note). Over the next decade, there will be no programming methods, the use of which will allow an order of magnitude increase in the productivity of development, all other things being equal. "
Among the main allegations of Brooks, which have become commonplace, include the following:
- The software product faces obsolescence even before its completion.
- Of all the designed systems, the second is the most dangerous. Usually it has to be redesigned .
- Plan to throw out the first version - you still have to do it, because it will not meet user expectations.
- You cannot evaluate software projects in person months. Man-month is a mistaken and dangerous delusion, since it assumes that months and the number of people can be interchanged.
- The best professional programmers are 10 times more productive than the weak.
- Brooks law: if the project does not fit the deadline, the addition of labor will delay it even more.
This is not all thoughts given in the book, but they seem to be the most important. It would be inappropriate to analyze all 214 statements, especially since many of them are quite obvious. For example, with the fact that it is best to have a small active team - you can not argue.
However, changes in the relevance of these statements reflect changes in the software development industry.
The first and second systems 50 years later
The software product becomes obsolete before its completion, the architecture of the second system will turn out bad, and the first one will have to be thrown out, because it will not satisfy the needs of users. It turns out that something sensible can come out only from the third time? Not. In a sense, Brooks is right, but we learned how to deal with it.
The software product will inevitably become obsolete before its completion , if you develop it for five years. That is what happened with System / 360. All modern approaches to development imply a quick release of the first version, albeit with a minimal, but practically useful set of functions. The same concept of user stories is primarily aimed at choosing a small but integral part of the entire set of customer needs for implementation. Then the product can be released quickly and get feedback.
The first version will have to throw out if you do it blindly. But if the first version is not too bloated, and in the process of its development the wishes of real users will be taken into account, everything can turn out quite well. With the beginning of use, many comments will inevitably appear, but if you listen to feedback before the first release, the chance of a complete failure is significantly reduced. Correct comments is not a problem, just to use the product.
The architecture of the second system will turn out bad . Project System / 360 Brooks considers it the second system. Specialized projects that IBM developed earlier turned out to be quite good, but from 360 they decided to do everything correctly.
Architectural decisions are not made from scratch, they are the answer to the problems. If the system develops evolutionarily, these problems are real and quite tangible. They can be disassembled, understood, and find a solution. Starting from scratch, it is very easy to miss what is really important for users - no one can foresee everything. However, it is nevertheless dangerous to fall into the trap of solving imaginary problems that exist only in the head of an architect / analyst, but have no relation to reality.
The problem of the second system as a whole exists, but we have learned how to avoid it without making the second system . Instead, the first released product develops evolutionarily and iteratively. Sometimes refactoring, migration, and backward compatibility are expensive, but it’s not such a big price to keep in touch with reality.
Ultimately, development sped up not technological development, but shortening the development cycle and getting quick feedback.
Mythical and actual man-month
Regarding the fact that when developing software projects, it is impossible to manipulate the estimates in man-months, Brooks is a little cunning. In fact, this can not be done in any project .
Planning the timing and resources of a project is a simple matter. If you know all the tasks, the dependencies between them, estimates of terms and necessary resources, then everything is quite simple. Only the lazy will not cope with the creation of a plan in such conditions. But even in this case, you can not add people endlessly to speed up the project. There is always a critical path that determines the minimum possible time, regardless of the amount of resources. For more on this, see "Project Management in the USSR (1976)" and "Critical Chain" .
Unfortunately, the conditions necessary for planning are not always fulfilled. In this case, make a correct plan is impossible . Even estimates of the timing of individual tasks are always obtained from practical experience . But what if there is no such experience? Tying shoelaces is a matter of minutes, or rather, 5-7 seconds. Tying shoelaces every day, we can from our experience accurately estimate how long it will take us to do this work tomorrow. But try to predict how long it will take for you to tie your shoelaces with one hand . Will your assessments match the actual experience? Curious experiment. Read more - Robert C. Martin "Effective Estimation (or: How not to Lie)" .
We are very bad at planning what we have never done, any new initiatives, not just software development. It was in this situation that Brooks found himself when he was asked to draw up a project plan, as well as an assessment of the timing and cost of developing System / 360.
Even if you lock up all the key professionals in the hotel, they still will not be able to make an exact plan for a large software project. Unfortunately, IBM management put Brooks in a hopeless situation, which probably prompted him to write a book later.
However, short-term planning is quite realistic. If you plan an iteration for 2-4 weeks, you can do it quite accurately. Over time, the skill of decomposing large tasks into smaller ones is acquired, and smaller tasks are easier to evaluate. In addition, constantly working in one direction, a person accumulates expertise. The tasks that three months ago seemed completely new, so that they could be evaluated only with a finger to the sky, turn out to be quite similar to the recent ones. Hence, the estimates of their dates will be similar.
Of course, it is impossible to evaluate software projects in person months, but it is quite possible to plan the work for the next month. And this plan for the next month will not be mythical, but quite reasonable, factual .
What did Brooks miss
- Mr. Brooks, you said that you will need two years and $ 625 million for the project, two and a half years have passed, you have twice exceeded the budget, but there are no results. Mr. Brooks, do you understand that the success of the entire company depends on the early completion of your project? We give you another $ 2 billion and hire you an additional 500 people.
“Mr. Brooks, your task is to complete all the necessary work during the next year.”
Of course, we don’t know if Brooks actually said this, but this could well have happened.
Brooks explains in detail and in detail why adding resources at the initiative of management cannot accelerate a protracted project. It is necessary to reschedule all the work, to spend time on introducing new specialists in the course of business, instill in them the rules of development, and so on. In all of this, Brooks is certainly right, but that's not the point.
The real problem of Brooks is not that it took four years to complete his project, and not only that the budget amounted to $ 5 billion, but that he was unable to plan precisely in advance neither the time frame nor the budget. In fact, he was wrong 10 times. Of course, Brooks is looking for a way to speed development in the same 10 times, but this is not a solution.
No one in the place of Brooks would have been able to give a more accurate, informed assessment of the project. Of course, someone else could say three years and two billion dollars, in this case the error would be less. But such a “more accurate estimate” would be the result of a successful guess rather than a rational prediction.
The main conflict of the book is that from a business point of view, you need to know exactly how long the project will take and how many resources it will take, and Brooks was forced to answer these questions. In reality, everything turned out quite differently as planned, for which Brooks feels a personal responsibility. He promised, he did everything he could, he did not succeed. But you must admit, it is not quite honest to demand from a person to make a promise that he most likely will not be able to fulfill.
Everything could turn out differently if, at the beginning of the project, Brooks insisted that the project budget could be from $ 1 to $ 6 billion, and the duration from 3 to 7 years, and it is impossible to give more accurate estimates. And IBM management, in turn, recognized these estimates.
Perhaps it would be better to plan the company's budget, knowing the possible risks of delaying the project and increasing its budget. This is better than running into a problem when the money has run out. Perhaps there would be a way to change the approach to promotion and sales, in such a way as to make it possible to minimize the scale of the project, make it less uncertain, and therefore less risky. Perhaps something else could be done that goes beyond the competence of the engineering department, which would help the success of the project. But at that time such a fundamental change in the approach to work was beyond the limits of what is permitted. There were very different times, the 1960s.
Source: https://habr.com/ru/post/343372/
All Articles