Systems Engineering Manifesto

Truly robust systems are primarily achieved through a combination of code reuse and consistent API design; these inform, and are informed by, the broader developer experience (e.g. team structures, workflows, etc.)

The degree in which code reuse can be achieved depends intrinsically on the cohesiveness of developer practice. Teams that use different architectures, programming languages, development approaches will find it all the harder to reuse code except at the edges of their practice.

Code reuse and consistent API design, and therefore the broader developer experience, are fundamentally economies of scale. Production systems rarely exist in a vaccuum, and thus the true robustness of a system is a function of all its dependencies; similarly, bugs in shared code are (potentially) experienced together, but are also solved together and for all consumers of a system.

Code reuse exists mainly in the space between integration and use, or in other terms, boilerplate and business logic. Boilerplate is assumed to be largely difficult to be made cohesive across systems, and business logic is assumed to inherently be what makes a system unique to its own needs.

These conceptions place artificial limits on the degree of code reuse even within individual systems, and solving this condrum requires rethinking of the definitions of boilerplate code, library code, and business logic, as well as the divisions between them.

All of these above principles exist both at the macro level, i.e. in the way disparate teams might participate in a service-oriented-architecture, but also at the micro level, i.e. in the way any given service is architected within a team, whether or not any external team or code dependencies are implied.