The Law of Diminishing Returns

Last month we looked at various approaches to scaling enterprise development, and the challenges found within development organizations in our Time for InnerSource? post. This month we continue looking at the need for InnerSource by taking a closer look at the Law of Diminishing Returns.

The law of what?

The Law of Diminishing Returns refers to a point at which the level of benefits gained is less than the amount of effort invested. Beyond a certain point, if you add too many people to solve a particular problem, the marginal cost increases and the output per person decreases. In order to avoid this situation, enterprises need to consider ways of working that avoid the contention that causes this effect. This is sometimes also described as the mythical engineer month, where the idea of adding 10x the number of people to get something completed does not mean it will get completed in 1/10^th the time. One of the main impacts of this problem is the same as having too many cooks in a kitchen, which is that if everyone needs to know everything to help, and everyone is working on the same things, there’s an amount of redundancy that becomes unavoidable.

Structured development

One aspect of InnerSource is the facilitation of structured development to reduce the impact of the law of diminishing returns. Teams of developers, working in a structured way, develop on a single set of code that addresses a particular domain of functionality. In the InnerSource world, this is often a combination of working methodology, software lifecycle and governance, and how to share and collaborate efforts in a way where goals are aligned.

Efficiency to scale

Through a well defined governance model, consistent ways of working and the right tooling, it is possible for enterprise development to scale dramatically with minimal inefficiency. When done well, there is a high degree of self-organization, but more importantly, it starts to allow enterprises to focus more on their business outcomes and less on the arduous task of managing software development delivery.

Shared foundation

With these goals in mind, a solid InnerSource implementation gives an organization the ability to create internal source code packages that can be shared across teams, reused across applications, and maintained over time without introducing issues or regressions across applications. With a solid approach to flexibility and separation of concerns, it becomes possible for a larger team to collaborate and get things done together more efficiently.

Conclusion

By employing the methods of InnerSource for creating shared source code packages that are governed and maintained efficiently, it is possible to increase development scale methodically without falling into the traps of diminishing returns.

Getting Help With Your InnerSource Strategy