Maladies of Large scale Software Design

When designing and maintaining large scale software architecture, certain rules need to be adhered religiously. In the absence of which the software starts degrading, maintenance becomes difficult, adding features becomes a nightmare and soon everything comes crashing down as a house of cards.

• Tiering/Layering your logical architecture – a clear logical separation between different layers lead to simplified code navigation and comprehension. The layers should also follow a strict and clear naming convention for all packages and types. One can make of tools to make sure the code follows the logical architecture and all dependencies are in order.
• Cyclical dependency – Adhere to the principle of well defined and cycle free application. Cyclic dependencies can soon lead to bloating of code. Even package should be validated for any cyclical dependencies
• NCCD (Normalized cumulative component dependency) is another factor that needs to be adhered. NCCD of compilation units must not be bigger than 7. If this value grows over the threshold, one should isolate layers and subsystem by only letting them have interfaces as entry points. Breaking cyclic dependencies can also shrink this metric considerably.

In addition to the above rules, one can also gauge the health of the software using additional metrics like

• Code Coverage– describes the degree to which the source code of a program has been (unit) tested. Popular tools to measure code coverage in Java are Emma.
• Code Complexity - is another measure that can used to identify and quantify the code maintainability. Factors like Cylometric Complexity, Halstead's software science metrics and Lines of code metrics are some of the factors. In fact, there is a measure called Maintainability Index that can be calculated by using the factors.
• Documentation - is another factor that be used to quantify code maintainability. Documentation can be your normal JavaDocs or the inline source code commenting. You have tools like JavaNCSS where NCSS ( non commenting source statements) that can be applied at class, method/function level
• Code Format - is not really a measure but is an indicator of the readability of the code. Tools like CheckStyle can help identify the code formatting problems (from non standard class headers, indentation issues to spacing, variable naming convention and so on). Any issues reported by the tool can be used an indicator of the maintainability of the code

From a programmer’s perspective, the following rules should be followed, that will help in building and maintaining a robust and lively system

• Use a consistent formatting and naming scheme
• Limit the access to types and methods
• Number of types in a package must not exceed 50
• Lines of code (compilation unit) must not exceed 700
• Number of method parameters must not exceed 7
• Cyclomatic Complexity must not exceed 20
• Use assertions to ensure pre-conditions and post conditions

Do share your best practices that you followed or came across when build or maintaining large scale software architectures.