Managing Complexity

Primary Imperative in Software Development

Managing complexity is the most important technical topic and known as the primary imperative in software development.

Software can inherently be complex; you need to write code which compensates for human limitations.
Most project fail because of poor requirements, planning, or management.
When a project fails for technical reasons it is often due to uncontrolled complexity.
- Software can grow so complex that no one understands it and one change can affect the whole system.
The solution is to divide a system into subsystems.
- The goal of all software design techniques.
- The more independent subsystems are, the more you can focus on one at a time.
Keeping routines short make them easier to understand.

Make Designs which are simple and easy to understand.
Avoid being ‘clever’.
Design should let you focus on one part while ignoring the others (abstraction/ compartmentalization).

Connections between the parts of the program are minimized.
Components do a single, simple, well-defined thing.
Use abstraction, encapsulation, information hiding.
Makes it easier to integrate, test and maintain § Changes don’t affect the whole program.

Coupling: A measure of interconnectivity and dependence between different modules within a code base.

When aspects of a system are highly dependent on each and intertwined they are referred to as highly coupled.
Alternatively, when the interconnectivity between modules are minimized, they are referred to as loosely coupled.
When modules have no interconnection among themselves then they are referred to as uncoupled.

Cohesion: A metric used to describe how focused a module is performing a particular task.

A module with high cohesion is one that has been designed with a well defined purpose and has minimized connections.
Alternatively, a module with low cohesion has a broader purpose and scope and may perform multiple unrelated tasks.
Generally high cohesion is associated with loose coupling, and is preferable to low cohesion, which is associated with high coupling.
There is a certain balance between the two, however, for instance if one where to write a very simple program or performance critical application, highly coupled, low cohesive code may outweigh the overhead required for loosely coupled and highly cohesive code.

Can add to the system without rewriting large parts of it.
Components (functions, classes, etc.) can be reused in other parts of the system.

##High fan-in

High fan-in: having a high number of classes that use a given class.

High fan-in implies that a system has been designed to make good use of utility classes at the lower levels in the system.

Low-to-medium fan-out: having a given class use a low-to-medium number of other classes.

A class does not use too many other classes.
High fan-out (more than about seven) indicates that a class uses a large number of other classes and may therefore be overly complex.

Use common organization and feel so developers will find it easier to work with.
Don’t start religious wars about formatting, use a standard.
Each part should not look like it was designed by a different person.
This would force later developers to constantly try to understand what is going on.