If you’ve ever talked with anyone in construction you may have heard the saying that concrete is guaranteed to do two things. It’s guaranteed to get hard, and its guaranteed to crack.
Software systems have a similar guarantee. They are guaranteed to get constructed the first time only once, and they are guaranteed to change. Okay, so maybe that is a rather pitiful analogy, albeit a true one.
As a Software Engineer, what important lesson should we gleam from this employment perpetuating realization? We know whatever system we have built or we are in the process of supporting is very likely to continue to be modified in the future. Are the systems we are building or extending designed for change?
A very typical, if not uniformly followed approach to system design is to decompose a system functionally. Our user stories (or Functional Requirements Specification document) indicate we have features A, B, and C. So, we create an A component, a B component, and a C component that implements those features. Now A relies on both component B and C for it to function properly and likewise B relies on C. A few weeks into the development of these components the Product Owner stops by and informs us that feature A needs to change just a bit. We overlooked 17 input values that must be incorporated. After a few frustrating moments we pull ourselves together and start reviewing the rework necessary to accommodate this late breaking change. All 3 components, the client, and the data model need to change. It’s not all bad news though, we can salvage about 35% of the work completed so far. That means we just have to add the new functionality for the new 17 input values and refactor 65% of components A, B, and C to handle the new requirements. Sound familiar? Ever been there? Perhaps in the past week or month?
Wouldn’t it be nice if we knew of a way to design our systems that embraced change? A way that resonates with the change and doesn’t cause the preverbal domino effect. What if we approach it in such a way that the design is entirely focused on encapsulating areas of change?
The good news it this has been done for over a decade by the IDesign.net architects. They refer to this approach as “Volatility based decomposition”. Using this methodology, we compose features by the integration of components that collectively satisfy the underlying use case. As a starting point the system is decomposed along two axes of volatility.
- At the same customer over time
- At the same time across customers
Considering the A, B, and C features, what could change across customers? What could change over time for a given customer? Designing components that encapsulate these areas of volatility will enable us to produce these feature by integrating these components. Therefore, when a change does occur we have essentially only one place to make it.