Software development success unleashes an insatiable demand for more complex software to be developed even faster and preferably cheaper. Completing more ambitious software goals requires scaling up software development.
At the recent Collision from Home virtual conference, Stephen Deasy, the Head of Engineering at Atlassian, explored the issues that affect scaling software development. Atlassian is a well-known supplier of software development tools including Jira and Trello. He said that “As you scale your software development, you will encounter various dysfunctional patterns such as, too many meetings, a push to add another person to the development team or creating a design that mirrors your org chart. Position your projects for productive success by keeping teams small, developing junior people, and adding entirely new teams when necessary.”
Scaling software development is not straight forward. Most non-IT managers intuitively think that simply adding more capacity, meaning people, will produce more software with no adverse impacts on unit costs or quality. After all, that’s been the long-standing experience with other functions like production, transportation, or warehousing. Unfortunately, this experience is not relevant and even dangerous when applied to software development.
What should a CIO think about when faced with the need to build on software development success? What makes scaling software development different? What are the failed approaches to avoid? What approaches can lead to success?
Stephen Deasy reminded his audience of some historical perspectives related to the problem of scaling software development that continue to be valid and relevant in today’s software world.
Conway’s Law
In 1967 Melvin E. Conway, a computer programmer, stated that “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure”.
Common failures in project organization and software architecture that arise from Conway’s Law include:
- Designing the project organization and the software architecture separately. The split will result in poor design choices and integration disconnects. Instead, design the project organization and the software architecture concurrently and expect to revise both as the project evolves.
- Designing a multi-level, hierarchical project organization. This approach will constrain software design to a small set of solutions that is highly likely to exclude the optimum solution. Instead, design the project organization as flat as possible with no more than 3 levels. A flat project organization is more likely to arrive at the optimum solution.
- Planning for success. Counter intuitively, rigid or detailed planning will produce an inflexible software architecture and software design. Instead, we will achieve more successful software when we expect to encounter failure, assume learning, and recognize the need for repeated adaptation.
- Designing the project organization to involve large teams because the planned system is large in scope. Large teams will produce disappointingly little software because of the enormous effort consumed by communication and coordination. Instead, organize several small teams that can each own a part of the functionality or architecture that the team can develop independently of others.
- Designing the project organization as a set of functional teams such as software developers, business analysts, DBAs or QA staff. Functional teams will create silos that march to their own priorities and don’t coordinate well. Instead, organize every teams to include all the skills necessary to accomplish the functionality or architecture assigned to the team.
Dunbar’s Number
In the 1990s British anthropologist Robin Dunbar proposed that there is a “cognitive limit to the number of people with whom one can maintain stable social relationships—relationships in which an individual knows who each person is and how each person relates to every other person.”
Dunbar proposed that humans can comfortably maintain up to 150 stable relationships. Therefore, a typical person might have up to:
- 4 – 5 intimate relationships.
- 12 – 15 trusted relationships.
- 25 – 35 close relationships.
- 75 – 100 casual relationships.
This observation about social relationships limits the effective team size for many activities including software development. Experience suggests 6 to 8 software developers per project team is the upper limit. The project team can be larger in total because it will include other roles such as project manager, business analyst, database administrator, data modeler, and infrastructure administrator. However, increasing the number of software developers will produce less and less software per software developer due to more effort expended for communication and to maintain relationships.
Concepts like pair programming can improve quality, reduce rework, speed orientation of new developers, and reduce the adverse impact on the project if a valued software developer leaves the project. While this idea adds to the headcount of software developers, pair programming renames the limit to 6 to 8 software developer pairs and increases cost.
This observation about the human cognitive limit also limits the number concepts or variables even a talented software developer can juggle in their mind at one time. This limit should consciously influence the complexity of the proposed architecture of the system. The project team should favor designs that consist of a larger number of smaller, crisply defined modules over designs that consist of a smaller number of larger, more complex modules.
The Mythical Man-Month
Fred Brooks, the world’s first computer architect and a software engineer, first published The Mythical Man-Month in 1975. The book’s central theme is that “adding manpower to a late software project makes it later”.
This observation is true because software development projects cannot be perfectly partitioned into truly discrete tasks that can be worked on independently by software developers. By contrast, the manufacture of widgets or the transportation of materials or finished goods by multiple trucks or railcars are independent tasks.
All software projects require fairly constant communication among the software developers to build software modules and database schemas that can successfully interact with each other. Therefore, assigning more programmers to a project running behind schedule will make it even later. This is because the time required for:
- Orienting a new software developer about the project detracts from the effort available to the software developer performing the orientation.
- Intra-team communication will consume an ever-increasing percentage of the calendar time available.
This table of example team sizes illustrates how the number of communication channels and therefore the communication effort grow exponentially by team size. In this example, each team member devotes only 1 hour to communicate with each channel or team member in a 40-hour workweek.
As the number of project team members grows their communication effort increases and their output decreases. On a large team, the communication effort will exceed total team capacity. In this situation, no time is available to perform tasks on the project plan and the project ceases to make progress.
What strategies would you recommend that can scale software development successfully? Let us know in the comments below.
