Propositions of The Mythical Man-Month: True or False?

1. Propositions of The Mythical Man-Month: True or False? Are The Topics Proposed in 1975 Still Valid?

2. Look back on the Topics from 1975 in 1995 to see if they hold True • Fredrick Brooks takes a look back on all the topics he discussed back in 1975 to determine if they are still valid

3. The Tar Pit • Programming a commercial program takes 9 times longer than a privately used programs. • Programmers still have the same joys and woes as before.

4. The Mythical Man Month • Good programs take time. • Putting proper time requirements on program development is difficult. • Brook’s Law: Adding manpower to a late software project makes it later!

5. The Surgical Team • Good programmers are 10 times more productive than poor ones even with same experience. • Fewest minds on a project is best • A surgical team can keep the few mind structure but still get the productivity of many workers.

6. Aristocracy, Democracy, and System Design • Conceptual integrity is the most important consideration in system design. • The ratio of function to concept complexity is the best test, which comes from a small group of minds that separates architectural effort from implementation with one person in control of concepts. • A concept integrated system is fast to build and much of software development can be done in parallel.

7. The Second System Effect • Good communication by the architect can give good estimates for the project and also influence implementation of the project. • The second project is the most dangerous a person will design due to over design. • OS/360 is a good example of this.

8. Passing the Word • The results and implmenation need to be consistent, very detailed, formal, and follow a standard. • Any questions that an implementer has for the architect should be answered, then well documented and published.

9. Why Did the Tower of Babel Fail? • There was a lack of communication which in programming leads to scheduling problems, functionality problems, and bugs. • A formal workbook can help with communication. • The workbook is all the documents of the project and should be made carefully and early. • It needs to be properly structured, visible and updated quickly. • It is important to note changes.

10. Why Did the Tower of Babel Fail? cont. • Organization reduces the amount of communication necessary. • The communication structure is a network not a tree, so special organization needs to be created. • Each subproject needs two leaders, the producer and the director. • They can be the same or one can be over the other

11. Calling the Shot • Estimating the total project time can’t be done by estimating coding time and adding other factors. • Programming increasing as a power of the program size which is estimated to be about 1.5. • Portman’s ICL data shows programmers apply 50% of their time to programming and debugging vs. other types of tasks. • Aron’s IBM data shows productivity ranges from 1.5K lines of code (KLOC) per man-year (MY) to 10KLOC/MY • Harr’s Bell labs and Brook’s OS/360 data show the KLOC/MY to be 0.6 for operating system works and 2-3 KLOC/MY for complier work. • Productivity can increase as much as 5 fold when using higher level programming languages.

12. Ten Pounds in a Five Pound Sack • Principle Costs in a program are memory, and unnecessary size is wasteful. • Size budgets must be set and followed by disk accesses and function assignments • System architects need to be careful that sub-teams don’t optimize their section of code so that it hurts the rest of the program. • Programmers need to be trained in techniques of specific languages too help space-time tradeoffs and use program libraries. • Most improvement break-throughs are done with new algorithms by redoing data representation.

13. The Documentary Hypothesis • Documentation is very important, even smaller projects, which includes manuals, internal documents schedules, etc. • Each document is a checklist to provide a warning if something goes wrong. • The project managers job is to keep the team going in the right direction through communication, the documents do the instructing.

14. Plan to Throw One Away • Alpha and beta versions of projects are important. • The alpha version will most likely be totally discarded and redesigned but is still given to the customer to buy time. • It is important to document changes made and keep number versions.

15. Plan to Throw One Away cont.:Plan the Organization For Change • Designing a changing organization is harder than designing a system for change. • The boss must keep the mangers and technical people interchangeable as abilities allow, and the barriers are only sociological. • This can be difficult to set up but with a surgical team it will make it a lot easier.

16. Plan to Throw One Away cont.:Two Steps Forward One Step Back • The cost of maintenance is about 40% the cost of development, and the more users the more bugs are found. • There is a decent chance that a bug fix will introduce another bug, so all the test cases must be run again. • Designing the program to have little side effects greatly pay off in maintenance costs. • The more fixes introduced into the program the more the design fails and makes the entire program require to be redone.

17. Sharp Tools • Debugging machines need maximum memory instead of maximum speed and it needs to automatically measure all the program parameters. • Setting computer usage time in blocks helps raise productivity. • Building a simulator early is very helpful especially when it is listened to. • High level languages improve productivity and debugging.

18. The Whole and The Parts • Designing the system before building is very important and needs to be reviewed by an outside source. • Gold’s experiment shows that the second debugging session will only reveal 1/3 of what the first session did. • Debugging will be harder and take longer than planned. • System debugging should only begin when component debugging is complete and components should only be added one at a time. • Code used only to test the system may take up almost 50% of the used code.

19. Hatching a Catastrophe • Schedule slippage is hard to stop. • It is important to have a schedule with specific goals. • Repeated schedule slipping is bad for moral, but hustling is great for teams. • The critical path chart tells which slip matters how much. • The actual status might be hard to get since a boss doesn’t want to reveal it. • A milestone schedule and completion document help get around this.

20. The Other Face • The face the user sees is the documentation is just important as the face to the machine. • The importance for documentation has not be instilled into programmers. • Most documentation does not overview enough. • It is important to keep the documentation in the source code. • It is important to document why things are rather than just how they are.

21. Image Sources • http://www.silverbulletinc.com/images/computermag.gif • http://www.livingorgandonor.org/Images/trans13.jpg • http://www.kirchersociety.org/blog/wp-content/uploads/2006/02/kircherbabel.jpg • http://mimikirchner.com/blog/images/3:18:tools.jpg • http://lerevdr.files.wordpress.com/2007/08/hiroshima-atomic-bomb.jpg

22. Questions?