1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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
From Program Quality and Programmer Productivity by Beck 1977 and Estimating Software Costs by Jones in 1998 in McConnell
Copyright © 2017 Curt Hill

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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. Copyright © 2017 Curt Hill

21. Copyright © 2017 Curt Hill