Actual person month
We at Wrike have a tradition of sharing with our team thoughts about books we have read. We thought for a long time that it would be nice to extend this initiative to our blog on Habrahabr, and now a good case turned up - the book of Mythical Man-month by Frederick Brooks .
The book can be called a classic folklore of development rather than a real guide to building a workflow. It reflects the problems Brooks encountered in organizing work on 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 correctly, but to raise problems that needed to be solved. It is interesting to understand what has changed in development since the 1960s.
Photo from the IBM archive
Before talking about the book itself, you need to understand the context. What the OS / 360 project really was, for what purpose it was developed and in what conditions.
System / 360 Development History
In the early 1960s, IBM was the absolute leader in the computer market. Its share was 75%. However, the prospects were becoming less and less rosy. 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 the entire periphery. Software will also have to be rewritten.
Expensive pleasure for the client, not everyone will decide on this. And for IBM itself, the situation looked bad. I had to support the production of obsolete equipment, maintain a staff of specialists who can configure it, and train engineers on the client side with obsolete 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, dispatch systems.
And so, in January 1961, the 29-year-old Brooks presents the project for the next 8000 series. Of course, the new system is better than the previous ones in everything, but in one it is the same. This is another completely unique complex, the transition to which will cost customers millions, as well as its support by IBM itself. Clearly, this is a dead end. The project is closed, and Brooks is invited to lead the team to develop a completely new system. But what no one knew. One thing was clear - the new system should provide backward compatibility in the future both at the hardware and software levels, and also be a general-purpose system suitable for banks, military and scientists.
A group of 25 people was formed, led by Brooks, who began to develop a plan for the new system. The process was moving slowly, and in order to speed it up, the management decided to relocate the working group to a hotel in a suburb 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 - OS / 360. It is ironic that the problems of backward compatibility were decided to be solved by refusing compatibility with previous systems.
The development of the system took significantly longer than planned, its cost was not $ 625 million, but $ 5.25 billion - a little less than the Appollo program with its rockets, astronauts and moon landing in the same 1965. The risk of bankruptcy for IBM was very real, but nothing happened. The announcement of the system took place on April 7, 1964, and the first products were released in mid-1965 . The success was tremendous. The principle of interchangeability of components laid down in the framework of this system is adhered to this day. By the way, it was after System / 360 that 8 bits became the standard byte size.
Brooks Key Statements
From the preface to the second edition: “This book is a belated answer to questions regarding 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 increase the development productivity by an order of magnitude, all other things being equal. ”
Among the main statements of Brooks, which have become commonplace, the following can be noted:
These are not all the thoughts cited 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’t 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 until its completion, the architecture of the second system will turn out bad, and the first 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 the third time? Not. In a sense, Brooks is right, but we learned how to handle it.
A software product will inevitably become obsolete before its completion if you develop it for five years. This is exactly what happened with System / 360. All modern development approaches 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 from a whole set of customer needs for implementation, albeit a small, but integral part. Then the product can be released quickly and get feedback.
The first version will have to be thrown outif 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 start of use, many comments will inevitably appear, but if you listen to the feedback before the first release, the chance of a complete failure is significantly reduced. Correcting the comments is not a problem, if only they would use the product.
The architecture of the second system will turn out bad . Brooks considers the System / 360 project to be the second system. The specialized projects that IBM developed earlier turned out to be quite good, but with 360 they decided to do everything right.
Architectural decisions are not made from scratch, they are an answer to problems. If the system develops evolutionarily, these problems are real and quite tangible. They can be disassembled, understood, and a solution found. Starting from scratch, it is very easy to miss what is really important to users - no one can foresee everything. However, it is equally dangerous to fall into the trap of solving imaginary problems that exist only in the head of the architect / analyst, but have no relation to reality.
The problem of the second system as a whole exists, but we learned to avoid it without making the second system. Instead, the first product released is evolving evolutionally and iteratively. Sometimes refactoring, migration, and backward compatibility support are expensive, but it's not a big deal to keep in touch with reality.
Ultimately, development was not accelerated by technological development, but by 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 estimates in man-months, Brooks is a little disingenuous. In fact, this cannot be done in any project .
Planning the timing and resources of a project is a simple matter of fact. If you know all the tasks, the dependencies between them, estimates of the deadlines and the necessary resources, then everything is quite simple. Only the lazy can not cope with the creation of a plan in such conditions. But even in this case, you can’t add people endlessly to speed up the project. There is always a critical path that determines the shortest 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, it is impossible to draw up a correct plan . Even estimates of the timing of individual tasks are always obtained from practical experience.. But what if there is no such experience? Tie shoelaces is a matter of minutes, or rather 5-7 seconds. By tying shoelaces every day, we can from our experience accurately assess how much time we need to do the same work tomorrow. But try to predict how long it will take you to tie the shoelaces with one hand . Do your estimates match real experience? A curious experiment. Read more - Robert C. Martin, “Effective Estimation (or: How not to Lie) . ”
We are very poor at planning what we never did, 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 estimate of the timing and cost of developing System / 360.
Even if you lock all the key specialists in the hotel, they still will not be able to make an accurate plan for a large software project. Unfortunately, the IBM leadership put Brooks in a hopeless situation, which probably prompted him to write a book later.
However, short-term planning is quite real. If you plan iterations for 2-4 weeks, this can be done fairly accurately. Over time, the skill is developed to decompose large tasks into smaller ones, and it is easier to evaluate small tasks. In addition, constantly working in one direction, a person accumulates expertise. Tasks that seemed completely new three months ago, so that they could only be evaluated with a finger in the sky, turn out to be quite similar to recent ones. Hence, estimates of their terms will be similar.
Of course, it is impossible to evaluate software projects in man-months, but it is quite possible to plan work for the next month. And this plan for the coming month will not be mythical, but quite justified, factual .
What Brooks missed
- Mr. Brooks, you said that you will need two years and $ 625 million for the project, two and a half have already passed, you have doubled the budget, but there are no results. Mr. Brooks, do you understand that the success of an entire company depends on the speedy completion of your project? We will give you another $ 2 billion and hire you an additional 500 people.
“Mr. Brooks, your task is to complete all the necessary work within the next year.”
Of course, we don’t know if this really was said to Brooks, but this could very well have happened.
Brooks explains in detail and in detail why leadership-driven resource additions cannot accelerate a protracted project. It is necessary to re-plan all the work, spend time on bringing new specialists up to date, instill in them development rules and so on. Brooks is certainly right in all of this, but that is not the point.
The real problem with Brooks is not that it took four years to complete his project, and not only that the budget was $ 5 billion, but that he was unable to accurately plan ahead for the deadlines or the budget. In fact, he made a mistake 10 times. Of course, Brooks is looking for a way to speed up development by the same 10 times, but this is not a solution.
No one at Brooks’s site could give more accurate, reasonable estimates of the project. Of course, someone else could say three years and two billion dollars, in which case the error would be less. But such a “more accurate estimate” would be the result of a successful guess rather than a rational forecast.
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 much resources it will take, and Brooks was forced to answer these questions. In reality, everything did not work out as planned, for which Brooks feels personal responsibility. He promised, he did everything he could, he did not succeed. But you must admit, it is not entirely honest to require a person to make a promise that he most likely will not be able to fulfill.
Everything could have turned 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 would be impossible to give more accurate estimates. And the IBM leadership, in turn, recognized these estimates.
Perhaps it would be possible to better 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 is already over. Perhaps there would be a way to change the approach to promotion and sales, in such a way as to reduce the scale of the project as much as possible, 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 radical change in the approach to work was beyond what was permitted. There were completely different times, the 1960s.
The book can be called a classic folklore of development rather than a real guide to building a workflow. It reflects the problems Brooks encountered in organizing work on 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 correctly, but to raise problems that needed to be solved. It is interesting to understand what has changed in development since the 1960s.
Photo from the IBM archive
Before talking about the book itself, you need to understand the context. What the OS / 360 project really was, for what purpose it was developed and in what conditions.
System / 360 Development History
In the early 1960s, IBM was the absolute leader in the computer market. Its share was 75%. However, the prospects were becoming less and less rosy. 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 the entire periphery. Software will also have to be rewritten.
Expensive pleasure for the client, not everyone will decide on this. And for IBM itself, the situation looked bad. I had to support the production of obsolete equipment, maintain a staff of specialists who can configure it, and train engineers on the client side with obsolete 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, dispatch systems.
And so, in January 1961, the 29-year-old Brooks presents the project for the next 8000 series. Of course, the new system is better than the previous ones in everything, but in one it is the same. This is another completely unique complex, the transition to which will cost customers millions, as well as its support by IBM itself. Clearly, this is a dead end. The project is closed, and Brooks is invited to lead the team to develop a completely new system. But what no one knew. One thing was clear - the new system should provide backward compatibility in the future both at the hardware and software levels, and also be a general-purpose system suitable for banks, military and scientists.
A group of 25 people was formed, led by Brooks, who began to develop a plan for the new system. The process was moving slowly, and in order to speed it up, the management decided to relocate the working group to a hotel in a suburb 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 - OS / 360. It is ironic that the problems of backward compatibility were decided to be solved by refusing compatibility with previous systems.
The development of the system took significantly longer than planned, its cost was not $ 625 million, but $ 5.25 billion - a little less than the Appollo program with its rockets, astronauts and moon landing in the same 1965. The risk of bankruptcy for IBM was very real, but nothing happened. The announcement of the system took place on April 7, 1964, and the first products were released in mid-1965 . The success was tremendous. The principle of interchangeability of components laid down in the framework of this system is adhered to this day. By the way, it was after System / 360 that 8 bits became the standard byte size.
Brooks Key Statements
From the preface to the second edition: “This book is a belated answer to questions regarding 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 increase the development productivity by an order of magnitude, all other things being equal. ”
Among the main statements of Brooks, which have become commonplace, the following can be noted:
- The software product is facing obsolescence even before its completion.
- Of all the systems being designed, the second most dangerous is. Usually it has to be redesigned again.
- Plan to throw away the first version - you still have to do it, because it will not satisfy users' expectations.
- You cannot evaluate software projects in man-months. Man-month is an erroneous and dangerous error, since it assumes that the 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 meet the deadlines, the addition of labor will delay it even more.
These are not all the thoughts cited 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’t 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 until its completion, the architecture of the second system will turn out bad, and the first 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 the third time? Not. In a sense, Brooks is right, but we learned how to handle it.
A software product will inevitably become obsolete before its completion if you develop it for five years. This is exactly what happened with System / 360. All modern development approaches 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 from a whole set of customer needs for implementation, albeit a small, but integral part. Then the product can be released quickly and get feedback.
The first version will have to be thrown outif 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 start of use, many comments will inevitably appear, but if you listen to the feedback before the first release, the chance of a complete failure is significantly reduced. Correcting the comments is not a problem, if only they would use the product.
The architecture of the second system will turn out bad . Brooks considers the System / 360 project to be the second system. The specialized projects that IBM developed earlier turned out to be quite good, but with 360 they decided to do everything right.
Architectural decisions are not made from scratch, they are an answer to problems. If the system develops evolutionarily, these problems are real and quite tangible. They can be disassembled, understood, and a solution found. Starting from scratch, it is very easy to miss what is really important to users - no one can foresee everything. However, it is equally dangerous to fall into the trap of solving imaginary problems that exist only in the head of the architect / analyst, but have no relation to reality.
The problem of the second system as a whole exists, but we learned to avoid it without making the second system. Instead, the first product released is evolving evolutionally and iteratively. Sometimes refactoring, migration, and backward compatibility support are expensive, but it's not a big deal to keep in touch with reality.
Ultimately, development was not accelerated by technological development, but by 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 estimates in man-months, Brooks is a little disingenuous. In fact, this cannot be done in any project .
Planning the timing and resources of a project is a simple matter of fact. If you know all the tasks, the dependencies between them, estimates of the deadlines and the necessary resources, then everything is quite simple. Only the lazy can not cope with the creation of a plan in such conditions. But even in this case, you can’t add people endlessly to speed up the project. There is always a critical path that determines the shortest 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, it is impossible to draw up a correct plan . Even estimates of the timing of individual tasks are always obtained from practical experience.. But what if there is no such experience? Tie shoelaces is a matter of minutes, or rather 5-7 seconds. By tying shoelaces every day, we can from our experience accurately assess how much time we need to do the same work tomorrow. But try to predict how long it will take you to tie the shoelaces with one hand . Do your estimates match real experience? A curious experiment. Read more - Robert C. Martin, “Effective Estimation (or: How not to Lie) . ”
We are very poor at planning what we never did, 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 estimate of the timing and cost of developing System / 360.
Even if you lock all the key specialists in the hotel, they still will not be able to make an accurate plan for a large software project. Unfortunately, the IBM leadership put Brooks in a hopeless situation, which probably prompted him to write a book later.
However, short-term planning is quite real. If you plan iterations for 2-4 weeks, this can be done fairly accurately. Over time, the skill is developed to decompose large tasks into smaller ones, and it is easier to evaluate small tasks. In addition, constantly working in one direction, a person accumulates expertise. Tasks that seemed completely new three months ago, so that they could only be evaluated with a finger in the sky, turn out to be quite similar to recent ones. Hence, estimates of their terms will be similar.
Of course, it is impossible to evaluate software projects in man-months, but it is quite possible to plan work for the next month. And this plan for the coming month will not be mythical, but quite justified, factual .
What Brooks missed
- Mr. Brooks, you said that you will need two years and $ 625 million for the project, two and a half have already passed, you have doubled the budget, but there are no results. Mr. Brooks, do you understand that the success of an entire company depends on the speedy completion of your project? We will give you another $ 2 billion and hire you an additional 500 people.
“Mr. Brooks, your task is to complete all the necessary work within the next year.”
Of course, we don’t know if this really was said to Brooks, but this could very well have happened.
Brooks explains in detail and in detail why leadership-driven resource additions cannot accelerate a protracted project. It is necessary to re-plan all the work, spend time on bringing new specialists up to date, instill in them development rules and so on. Brooks is certainly right in all of this, but that is not the point.
The real problem with Brooks is not that it took four years to complete his project, and not only that the budget was $ 5 billion, but that he was unable to accurately plan ahead for the deadlines or the budget. In fact, he made a mistake 10 times. Of course, Brooks is looking for a way to speed up development by the same 10 times, but this is not a solution.
No one at Brooks’s site could give more accurate, reasonable estimates of the project. Of course, someone else could say three years and two billion dollars, in which case the error would be less. But such a “more accurate estimate” would be the result of a successful guess rather than a rational forecast.
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 much resources it will take, and Brooks was forced to answer these questions. In reality, everything did not work out as planned, for which Brooks feels personal responsibility. He promised, he did everything he could, he did not succeed. But you must admit, it is not entirely honest to require a person to make a promise that he most likely will not be able to fulfill.
Everything could have turned 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 would be impossible to give more accurate estimates. And the IBM leadership, in turn, recognized these estimates.
Perhaps it would be possible to better 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 is already over. Perhaps there would be a way to change the approach to promotion and sales, in such a way as to reduce the scale of the project as much as possible, 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 radical change in the approach to work was beyond what was permitted. There were completely different times, the 1960s.