Why complexity matters? Cost. Lean Software Development recognizes the cost of complexity is exponencial and dominates over all other costs. It’s easier, cheapest, and smarter to address complexity in earlier stages of the software development lifecycle.
On this article, I explore it from engineering side which starts on design phase. An engineering team engages to construct a solution to fulfill the customer functional needs in form of functional requirements (FRs). Depending how the FRs are addressed by the architecture decisions can impact on the complexity. To address complexity on engineering design there are two axioms extracted from Axiomatic Design Theory that helps:
- Complexity Axiom 1, The Independence Axiom. Maintain the independence of the FRs.
- Complexity Axiom 2, The Information Axiom. Minimize the information content of the design.
On software design, coupling is a term to talk about independency. Different authors explore dimensions of coupling such as architecture coupling, infrastructure coupling, deployment coupling, runtime coupling, and so on… Coupling will be present in one way or another and engineers should be intentional about design decisions to identify the best strategy to guide the development. The use of Axiom 1 and 2 as tenets helps to make this decision.
Often the system of interest is already in an ongoing state. An indicator that you have a complex software is how painful is each change. Complex code breaks easily and it’s hard to change. The key is to prioritize simple, clean, and small codebase. Refactoring as process and patterns is helpful to address complexity on codebase.
On coding, conditional logic introduces complexity. Transform or remove conditional logic using patterns among solid unit testing coverage compose the way that Refactoring recommends. From Refactoring Catalog (on the book chapters contains the step-by-step how to apply each pattern): Decompose Conditional, Consolidate Conditional Expression, Replace Nested Conditional with Guard Clauses, Replace Conditional with Polymorphism, Introduce Special Case, Introduce Assertion, Replace Control Flag with Break.
On unit tests, …planned for future reviews…