I recently read an article by Matt Ricard about the “Heptagon of Configuration” in which he discussed how configurations evolve in a cycle.
It struck me that there’s another thing that follows a similar routine – entity attributes. Entity attributes often grow into complete systems in their own right.
- Tax number grows into tax records and engines.
- boolean flags grow into multi-valued state machines etc
The entity evolution cycle
This is the transition as I’ve seen it go in my experience.
- Some new, urgently required properties of an entity are modelled as a hack in a configuration somewhere.
- This configuration is then pulled into the entity’s main data mode, typically as a boolean attribute.
- Boolean attributes evolve into named/enumerated types, sometimes with more associated data.
- Enumerated types become full-fledged entities linked to their previous host entity
- Entities evolve into complete business domains with their systems, process, almost organizations.
This iterative process happens because as we explore more use-cases, an increasingly complex domain model emerges. The pentagon of entity model evolution is a sign of developers trying to keep up with a deeper understanding of the business but not yet knowing enough to model its nuances fully.
I interpret technical debt in a similar manner – as wisdom in hindsight. The system’s implementation is essentially just catching up with the developer’s understanding of the problem domain.
The pentagon is a perfectly safe, natural way for systems to evolve. But if you want to crank the wheel a little faster, the way to move fast but stay on track is to spend more time understanding the business domain upfront. Understanding the domain better can help us predict future needs and build the necessary extensibility, if not the actual capabilities in our designs right away.
If you liked this, subscribe to my weekly newsletter It Depends to read about software engineering and technical leadership