[TEST] 2.1: The Rise Of Open Source Dramatically Improved Reusability

In 2000, 85% of a system was coded, and 15% was composed through infrastructure, library, and module reuse.

In 2022, it’s a composition world where 85% of a system comes from package reuse, and 15% is from custom logic.

Reusability is a double edged sword. On the one hand, a developer gets to avoid having to reinvent a task by using a module that specializes in that task.

On the other hand, as reusability increases, it turns into layers of transitive reuse. Modules at higher levels reuse modules from lower levels. Sometimes multiple modules that you reuse share other modules in a similar fashion. The relationship between modules and their reuse is a transitive graph. Organizations (and developers) need to understand the full transitive graph of their dependencies, their dependencies dependencies, and so forth all the way to the root code. They must understand these issues for performance and security reasons, as those dependencies could be a bottleneck or attack vector.

As reuse grows, the complexity of the transitive graph tends to grow logarithmically. Developers have traded off one form of code complexity for reuse complexity.

2.1.1: Build Automation Systems Facilitate Managing Dependency Complexity – To A Small Degree – Leading To Dozens Which Dev Teams Must Choose From.

Build systems use automation through the form of scripting or other programs to turn source code into runnable binaries. In order to appropriately create the right binary, many build systems have to maintain an internal structure of the various dependencies. As a result, making use of the build systems imposes some reasonable order and structure onto the transitive dependency graph.

As such, for as much variation that exists in programming languages, there can be as much variation in build automation systems. Some build systems are pinned to the unique structure of a single programming language while others work across languages.