Just like a company, a codebase comprises many elemental components with countless interdependencies. At the elemental level, this is far too complex for human comprehension, and developers are after all human. If they cannot comprehend a codebase, they cannot develop it efficiently. To understand and evolve all the detail, it is necessary to organize the functions, files, classes, etc. into well-structured, higher-level containers, which can be understood without understanding all the detail, and who’s relationships with other containers is clearly defined. This is the basic principle of abstraction, divide-and-conquer, modularity.
Comprehension is just the beginning of what is at stake here. A well-structured containment model serves as a blue-print or roadmap for developers; allows for phased testing and release of subsystems; enables the division of labor across organizations, teams, and individual developers; shelters components from changes to the internals of other components; allows subsystems or layers to completely replaced; helps new developers become productive quickly; etc. etc. etc. In short we are talking about a spectrum from chaotic, ad-hoc development, through to true agile software engineering.
The talk will show why poor structure has such a negative effect on the various aspects of production listed above, and quantify the complexity behind this effect.
Just as a company with 6 employees requires a drastically simpler org chart and inter-departmental controls than a company of 600 employees, structure is less critical in the early stages of a software development. At a certain size however, the explosive increase in complexity caused by the exponential growth of dependencies makes it essential to continued development velocity. Almost invariably this point is overshot and projects find themselves in very deep complexity debt before the need is realized.
The talk then shows how to organize the files in the codebase into a cogent containment model (or architecture) with minimal impact on the working code. There are 3 angles of attack. First, if there are any large groups of cyclically dependent classes, these should be disentangled, and the process for doing this is explained. Second, existing physical arrangements of source files into e.g. packages, folders, namespaces, etc. can serve as a start point. Thirdly, it is possible to discover cohesive groups of classes and organize them recursively into a containment hierarchy.
The architectural discovery cannot be achieved without the help of “code-first” modeling tools such as Structure101, Lattix, and SonarGraph. Short examples using Structure101 will be shown so as to make the principles more concrete. All the main tool options in this space will be briefly mentioned.
The clearly articulated connection between quantifiable complexity and the efficiency of development activities, and specific practical steps to reduce complexity and drive up development agility, is new, and offers potentially huge savings to our industry.