1 / 22

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

Propositions of The Mythical Man-Month: True or False?. Are The Topics Proposed in 1975 Still Valid?. 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.

milek
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related