Home

Book-Summary - The Mythical Man Month - Essays on Software Engineering

This is considered as one of the classics of  Software Engineering. These are my take aways from this book -

  • It is usually advertised that few programmers in a garage have developed a program which surpasses the best effort of large teams of a company - Do not believe that. There is a large difference between program and product/application/system. It takes a lot of effort to move the program to a product/system/application. 
  • What is it that makes a person to create programs - sheer joy of creating things, sheer joy of making things that is useful to others, joy of developing or imagining the complex systems and make it work - like solving a puzzle, joy of  learning as every time its a new thing we learn as tasks become non-repetitive.
  • When we are estimating a task, the general tendency is assuming everything is going to be well and only estimating for the coding. There are 3 parts in the creation - idea, implementation and interaction with real world. When we give estimates, we assume that our idea is perfect and implementation will be very easy. But usually idea will not be bug free and real challenges starts appearing once we start the implementation. So, when estimating, think of iterations of 3 parts, i.e take into account - planning, coding and testing. More time should be devoted to planning and testing. This type of estimate should be done for each task.
  • We should not equate the effort spent on a work to be equivalent of progress done in that work
  • Man and Month are interchangeable  only when each task can be divided such that there is no need for communication. For most of the time as more men means tasks needs to be divided and each task may not be perfectly independent of each other. So, if we estimate for a task that it takes x days for a single developer, it does not mean it is going to take x/2 days for two developers. The common mistake is adding more people to a late project to make the deadline achievable. But this is a mistake, adding more people to a late project will most probably will make it take a longer time. Adding people has two affects, new people have a learning curve and adds extra communication requirement. So, immediate effect of adding more people is negative. So, it is better to add more people in the early stage of the project.
  • When a project is not finished in time(food ordered in hotel), there are 3 possible things - 1. Give it as it is, that is it will be missing some features (half baked food) 2. Wait till the product finishes (wait for the full completion of the food) 3. Add more people to make it finish within the time line (increase the burner to cook it fast). The general tendency is to go with 3rd option which will always result in burned up product (burned up in one side and half baked in another side so totally a disaster). Best option is always 2nd option - wait till it finishes i.e extend the deadline. Next best is always for the releasing with limited features.
  • Until estimating is on a sounder basis, software managers should defend their estimates that their hunches are better than wish derived estimates.
  • Always have smaller teams. In the team for a product, there should be a single main developer who will be responsible for the design. This developer should be responsible for settling any queries related to design or architecture of the team. The others in the team should help this designer. Similarly, the main developer will take help and suggestions from his team. Always have a small and good programming team.  The architect/designer holds final decision and authority on the changes. Even during the meetings that chain should be well established to make the meeting fruitful. In the meeting everyone is allowed to discuss and propose the solutions which may be inside the boundary or outside. It is essential to encourage others to ask questions to the architect instead of assuming things.
  • If you are designing a module or product and the implementation will be done by others, then provide a possible implementation for it. Also be ready to accept the changed implementation done by the implementer as long as it sticks to the design.
  • If you achieve conceptual integrity in product design then simplicity will be automatically achieved. Even though a product may be developed by multiple persons in a team,  but it should be developed such that for an external user it should be perceived as developed by a single mind. It would be better that single person in the team should own the design of the product. One of the main ingredient of the successful product is having conceptual integrity.
  • As we add more features to a single product, it will reduce the usability of the product. As a designer or product owner, we want to add more and more features to it. After some point this will result in loosing conceptual integrity of the product and will have negative effect.
  • There are six ingredients of a successful product - clear mission, enough man power, enough time, enough materials, adequate technology and clear communication.
  • Organisation is there to help reduce the unnecessary communications and extra coordination which gets added as man power gets added.
  • For every team there are two aspects - technical and management.  So for each of them we need a point of contact - technical (director/architect), management (producer/ manager). Now these two roles can be done by a single person or it could be two different persons - one working under other (producer under director or director under producer). Manager’s work is mainly communication outside the team where as director or architect communication is within the team. Manager is responsible for getting the resources, establishing schedule, gathering team, dividing work. The Architect/director is responsible for design of the product, coming up with the sub designs, clearing the technical challenges. 
  • Before starting the program or product, along with the design, define the restriction under which that product needs to work. The restrictions like memory consumption limit, latency limits, CPU utilisation limits, request limits.
  • Forecast -> Estimate -> Price -> Forecast .This is a cycle. To generate forecast we need the postulated prices. Based on the forecast and the number of units, we derive the cost estimate. Then based on the estimate we set the price.
  • In most of the projects, the first product that comes out is barely usable. It will have lot of bugs, memory issues, may be awkward, big or small or not covering needed requirements.  So start with a prototype. After prototype, then only go with actual delivery. Develop the product with change in mind. The product grows and change is constant.
  • The reluctance to document a design is not merely for laziness or time pressure but also due to not wanting to commit to a design.  Any architect or designer should be ready to expose whole of the design, ready to defend everything he writes and expose himself to criticism. Organisation should help architect to achieve it and also make sure that architect is not threatened to take the responsibility.
  • Each person in team should be given the job which will broaden them.
  • In an organisation or team, managers and technical people should be interchangeable as their talent allow. Sociological barriers for bringing this into effect are -
    1. Managers often think of senior people as too valuable to use for actual programming.
    2. Management jobs carry higher prestige. To tackle this maintain dual ladder of advancement - Managerial Ladder (Senior Software Development Engineer -> Manager -> Senior Manager -> Vice President) , Technical Ladder (Senior Software Development Engineer -> Principal Engineer -> Senior Principal Engineer -> Director) . Corresponding Levels should have same base pay example - Manager and Principal Engineer should have same base pay salary  and other org support. A reassignment from the technical ladder to corresponding level on managerial ladder should never be accompanied by a raise as it is a reassignment and not a promotion.  Managers need to be sent to technical refresher courses, and technical people to management training. Project objectives, progress, technical problems and management problems must be shared with the whole body of senior people. Whenever talents permit, senior people must be kept technically and emotionally ready to manage groups or to delight in building programs with their own hands. 
  • Total cost of maintaining a delivered product is nearly 40% of the production cost. Most of the maintenance will be related to fixing design bugs. Usually as we go about fixing the bugs and releasing new versions, the total incoming bugs reduces and after certain point this incoming bug rate will again start increasing due to some reasons like -
    • users have learnt the product fully and are utilising it completely and hence new bugs are found,
    • design has reached its limits, so fixes are introducing newer bugs.
  • Test driven development is needed to build the product which does what is intended to to do.
  • When one hears of disastrous schedule slippage in a project, he imagines that a series of major calamities must have befallen it. Usually the disaster is due to termites, not tornadoes.  The day by day slippage is harder to recognize, harder to prevent, harder to make up. Each one of the team would have postponed their activity by a half-day or a day but overall project would have slipped one day at a time.
  • We need to have a schedule for a project. The schedule should be divided into milestones. Milestones must be concrete, specific, measurable events defined with knife edge sharpness. Rarely will a man lie about milestone progress, if the milestone is so sharp that he can’t deceive himself. If the milestone is fuzzy than boss will understand different report from that which the man gives. No one enjoys bearing bad news either, so it gets softened without any real intent to deceive.
  • We should clearly know which other modules are dependent on our module. So when we have a day slip in our module, that is going to have snow ball affect on modules that depend on us.
  • Every manager should get two kinds of information from direct reporters - action information and status information. Status information is just an education of what is going on and what is the current status of each items or milestones. This status information might have some red signals but manager or boss should not act on it. The first line manager or engineer who is reporting will take necessary action by himself. Only action information needs to be taken up by the Manager and act on it. We need to empower the first line managers and engineers to take ownership, own their tasks, work on issues and roadblocks but we need to have clear picture of what is going on. Only when the manager/engineer knows his boss will accept status reports without panic or preemption, he comes to give honest status.
  • The power should be delegated to individual teams. Any success or failure the team should own it. Any problems within the team needs to be settled within the team. The teams need to be empowered. The team should own the schedule of the project/product. They should have a process for this, either their own way or company followed standards. “The centre gains in real authority by delegating power, and organisation as a whole will be more happier and prosperous.”
  • On large projects manager needs to keep 2 or 3 top programmers as a technical cavalry that can gallop to the rescue whenever the battle is thickest. 
  • One of the important factors that will determine a success of a team is its quality.  More than better tools it is the team dynamics that matter - how the team is looked after, feeding them and taking care of their needs. Managers work is not to make people work but rather make it possible for people to work. The top performer’s workspace is more quieter, more private and better protected from interruption. So manager should target to achieve that for their teams - less interruption and quieter environment for the team.