The Effects on Development Program Size The Effects on Development Mythical Man Month by Fred Brooks Chapter 27 of Code Complete by Steve McConnell Copyright © 2017 Curt Hill

Introduction We have this naïve view of how difficult programs are to construct We think that doubling a program’s size double its complexity We think that converting a program for our use to anyone’s use is easy We think making an existing program part of a system of interrelated program should be easy We are wrong on all counts Copyright © 2017 Curt Hill

Fred Brooks Wrote a very influential book: The Mythical Man Month First published in 1975, updated 1995 First decried the practice of adding people to behind schedule projects He came up with the following graphic Copyright © 2017 Curt Hill

Evolving Programs A Programming System A Program A Programming Product Interfaces, System Integrarion 3X 3X 3X A Programming Product Generalization, Testing, Documentation, Maintenance A Programming Systems Product 3X Copyright © 2017 Curt Hill

Commentary The original program was suitable for some purpose To make it a purpose that anybody can use requires three times the work It must also be maintainable by anyone To integrate it into a system of programs takes a similar magnitude of work This does not even speak of how effort grows with size Copyright © 2017 Curt Hill

Staff and Communication Two team members One communication line Four team members Six communication lines Six team members Fifteen communication lines The communication lines to not go up linearly Copyright © 2017 Curt Hill

Commentary Larger projects often imply larger teams Yet larger teams have less productivity Number of communication lines is a contributor to this Not the only one Copyright © 2017 Curt Hill

Range of Sizes Projects may vary in size A survey in 1983 found this distribution 1-3 members account for 25% 4-10 members account for 30% 11-25 members account for 20% 26-50 members account for 15% 50 and more members account for 10% Big projects need big teams Partitioning the project may shrink a team From A Survey of Software Engineering Practice: Tools, Methods and Results by Beck and Perkins 1983 in McConnell Copyright © 2017 Curt Hill

Quality and Errors Larger projects produce more errors and different types of errors On small projects the largest factor on errors is the skills of the developers On large projects these are still the greatest contributor Architectural and requirements errors make a relatively much larger contribution Copyright © 2017 Curt Hill

Error Density Surveys found this distribution of error per size Size of project in KLOC Error Density in errors per KLOC < 2 0 – 25 2 – 16 0 – 40 16 – 64 0.5 – 50 64 – 512 2 – 70 > 512 4 - 100 From Program Quality and Programmer Productivity by Beck 1977 and Estimating Software Costs by Jones in 1998 in McConnell Copyright © 2017 Curt Hill

Productivity The size of the team contributes to productivity Similar to quality Smaller teams are more productive than large teams Copyright © 2017 Curt Hill

Productivity Survey Size of project in KLOC LOC per staff year 1 2,500 – 25,000 10 2,000 – 25,000 100 1,000 – 20,000 1,000 700 – 10,000 10,000 300 – 5,000 From Program Quality and Programmer Productivity by Beck 1977 and Estimating Software Costs by Jones in 1998 in McConnell Copyright © 2017 Curt Hill

Productivity There is a lot more to productivity than team size Experience and skill of the developer Kind of software being developed Tools available to the team Software development methodology Programming language Complexity of the project Despite these factors team size is as well Copyright © 2017 Curt Hill

Development Activities The percentage of time spent in various activities in the development process changes as the size of the project increases In small project the construction is the largest factor Construction includes Detailed design Coding and debugging Developer testing Copyright © 2017 Curt Hill

Sizing Projects of a few thousand lines typically spend 60-70% of the time in these construction tasks As the project rises to more than a hundred thousand this percent reduces to less than half These activities do increase In its place Integration, System testing and Architecting all increase at faster rates Copyright © 2017 Curt Hill

Another Study For projects less than 10 KLOC the lowest cost was obtained by spending about 5% on requirements and architecture For projects around 100 KLOC the lowest cost was obtained by spending about 10% to 15% on requirements and architecture Boehm and Turner cited by McConnell Copyright © 2017 Curt Hill

Methodology The methodology must vary somewhat with size An informal approach works with small projects A projects get large a more formal approach is required One of the aspects of the level of formality is paperwork Copyright © 2017 Curt Hill

Paperwork Paperwork is not a punishment Rather, it is a communication mechanism Small teams may communicate with meetings As the teams get larger this is problem A project which produces about 1 KLOC will average 7% of its effort in reports and other documentation A 100 KLOC will average 26% of its effort in this category Copyright © 2017 Curt Hill

Finally Linear growth of work generally does not happen in software development projects Large projects usually cannot tolerate using a small team for a very long time Large teams suffer from communication issues These issues take more time and cause more errors Copyright © 2017 Curt Hill

Copyright © 2017 Curt Hill

Copyright © 2017 Curt Hill