- Level 1: Reachable / Solving
- Level 2: Minimal / Maintainable / Environmental
- Level 3: Agile
- Level 3.1: Extensible
General Explanation
The Maturity Index provides a way of reasoning about the maturity of a process, product or output.
Our personal and organisational values influence not only how we think, but also the things we create. We are also adaptable and ever changing beings, so we adapt our values over time. Differing contexts and situations also influence our values and thus our behaviours.
Throughout this summation, a comparison will be drawn against the Capability Maturity Model Integration (CMMI) developed by Carnegie Mellon University, which is known and used across various industries. Similar concepts can be found in many methods, including Edward Deming’s "Theory of Profound Knowledge" which describes “Just Enough Not Too Much”, and concepts like Just-In-Time (JIT) from compilers, or anti-patterns like "eager evaluation" These are different sides to the same kinds of philosophy.
- We need to act
- We need to learn
- We need to optimise
The following describes the concepts based on the Maturity Index which uses the seven principles.
Level 1
Values: Reachable (R) and Solvable (S)
Our first processes are born out of necessity and are not well-defined or controlled. CMMI calls this Level 1, "Initial". We say that the fundamental values that govern our behaviour are Reachable and Solvable.
Reachable is a value that promotes getting tasks done within a period or a budget. It tends to be our primary concern at this stage. There are various reasons for this, but it influences how we design, create and act. This kind of process or product is often easy to spot, by its single-minded motivation to reach the goal.
The goal for level 1 is a solution to one or more problems. These two values drive the tasks. We want to get the problem solved within a time frame. This mindset results in a very unpredictable and poorly controlled process, codebase or solution.
Level 2
Values: Minimal (Mi) / Maintainable (M) / Environmental (E)
When we have a solution or processes in place, our next steps are to invest in their optimization. The values of Minimal, Maintainable and Environmental begin to take hold. We are now the equivalent of Level 2 with a beginners eye of Level 3, 4 and 5 on the CMMI maturity levels, where we are defining and beginning to manage the processes.
We seek to reduce unwanted processes, ensuring a more lean approach.
Our value of maintenance is also pushed forward, where we seek to optimize areas for maintenance efficiency. We design and shape what we have to reduce the time it takes to ensure the solution continues to run as expected.
Environmental aspects begin to matter as we seek to make more alignment with outside departments or processes. We seek to align with standards or conventions.
Level 3
Values: Agile (A)
When we value agility, we manage our processes with a sense of adaptability. We begin to monitor and manage the processes as we did in level 2, looking at adaptability. Our focus is to make these aspects more adaptable.
Akin to Levels 4 and 5 in the CMMI maturity levels, we are measuring and improving processes, focusing on adaptability and efficiency when dealing with change.
Level 3.1
Values: Extensibility (Ex)
When we understand enough and learn enough about our systems, that we begin to start controlling agility, we can look to Extensibility as the ultimate goal.
Extensibility is the most mature form of adaptability, where the environment is suited for adding additional steps with little effort and no adjustments to the existing structure.
Software Design Explanation
Software design is a significant undertaking, and systems can quickly become highly complex. We are also at odds with under or over-engineering, where the line is unclear. The software also undergoes maturity, and over time, certain aspects of the software can be visible.
Level 1: Just Enough
Values: Reachable and Solvable
When we concentrate on Solving and Reachable values, we are concerned with solving a problem on time. This may not be the best code, nor may it be the most robust. We must prove the case, research the problem, understand the context and deliver something. What we deliver can be checked and verified to reach the solution. When we do ‘just enough’, we understand that the design is not robust or maybe even satisfactory for release, but we know we can solve the problem.
This concept is well known. Test-Driven Development goes through a cycle of red-green-refactor, to do “just enough”, to then refactor towards a “better” solution or a more eloquently written version. If TDD is our example, "Just Enough” would encompass the red-green part of the equation.
Level 2: Solidifying the solution
Values: Minimal (Mi) / Maintainable (M) / Environmental (E)
After knowing that we can solve the solution, we bring forward the values of Minimal, Maintainable and Environmental.
Minimal
Minimal is a mixture of activities.
- Reduce the code to the leanest solution
- Create a design (interfaces/functions/classes) that wraps the problem-solution
- Ensure only required dependencies
- Aim to reduce dependencies
Maintainable
- Ensure coding conventions are adopted
- Ensure naming conventions, descriptive code and/or comments
- Ensure high cohesion
Environmental
- Ensure the code behaves as expected within its runtime and language, not behaving against expected behaviour
- Ensure developer experience is good, with low learning curve and documentation
- Abide by team rules, guidelines and conventions
Level 3: Code for Agility in design-time
Values: Agile (A)
- Ensure what has high rates of change are configurable and adaptable
- Ensure your design deals with common kinds of change
- Ensure hotspots, events and other mechanisms allow agility
- Ensure a clear path to extended functionality in code, with polymorphism and other mechanisms
- Ensure the design is a white-box
Level 3.1: Solving tomorrow's problems
Values: Extensibility (Ex)
The best form of agility to when you do not have to recompile
- Ensure a run-time plug-in mechanism allows for extending the solution
- Ensure an ecosystem, API, SDK or other can allow extensible solutions without compilation of the core code
- Ensure algorithms, processes, pipelines are extensible
- Ensure the design is a black-box
Evaluating Existing software
You can easily evaluate software and assign a Maturity Index to the code.
- Does not solve an obvious domain oriented problem (level 1)
- Look for areas where it is not Environmental (where it differs from conventions used elsewhere or from the runtime) (Level 2)
- Look for optimizations, where code is not minimal or easily maintainable (Level 2)
- Look for white-box design patterns, like strategy, template methods (Level 3)
- Plugin mechanisms or ecosystem (Level 3.1)
When you divide software into functionality or modules, you can evaluate them separately.
If you want to improve your software, evaluate and ensure your software achieves each successive level. Note: All areas do not have to achieve the highest level, but every quality software with have Level 1 and 2 completed with the right areas achieving Level 3 and 3.1.
