Model Plasticity: A fundamental concept in Software Engineering
Software systems can be expressed using different models. We can have requirements captured as a document or a series of user stories. We can have design documents and UML diagrams. Ultimately, we can have working code. Each of these representations describes the same system, but at different levels of abstraction. Because of this, they differ not only in purpose but in how easily they can be changed.
This idea of how changeable a model is can be captured with a single concept: model plasticity. At an intuitive level, plasticity refers to how easy it is to reshape or modify a model. Requirements are usually the easiest to change. Design comes next. Code is typically the hardest. This is different from Kent Beck’s definition, because we are talking about the ease of changing the model, not the finished product.
However, describing plasticity only as “ease of change” is too vague to be useful. We need a clearer way to think about what makes a model easier or harder to modify. There are several concrete ways we can interpret “ease of change”:
- the time needed to modify the model
- the mental effort required to understand the effects of the change
- the likelihood of success when attempting the change
All of these point toward a more structured idea, but fail either by not capturing all of the useful aspects or by not defining a quantifiable metric. The likely most useful and quantifiable definition is:
Model plasticity is the inverse of the cost of changing a model.
Without a specific change in mind, measuring the cost of change is extremely difficult. But we can measure the factors that contribute to the cost of change and extrapolate the cost. These factors can be grouped into categories:
Model intrinsic factors
- specificity - to what level of detail are we modelling the system
- coupling or the amount of related material that must be understood for a change
- abstraction complexity - how complex are the concepts we are using to model the system
Human or agent factors
- skills with the relevant technologies
- system familiarity - how well does the agent/human know the system and the domain
- cognitive capacity - this could be IQ or some agent specific benchmark like SWE-Bench
- available capacity such as team size or computing power for agents
Process and organisational factors
- development processes
- review and approval practices
- communication overhead between different actors
- presence and quality of feedback mechanisms
Economic and strategic factors
- cost of developer or agent time
- opportunity cost of using limited resources
- competitive pressure to change quickly
- risk tolerance and the cost of failure
Tooling and automation factors
- available tools
- level of automation such as tests or refactoring support
- environment or infrastructure friction
By understanding these factors, teams can better anticipate where plasticity will be high or low and adjust their approach accordingly.
Is Model Plasticity Always Desirable?
High plasticity is not always desirable. Plasticity captures only one dimension of model suitability.
Models with high plasticity are also not necessarily more useful. A requirements document cannot run. A design diagram cannot validate behaviour. Their value comes from supporting change, not executing it.
In addition, plasticity does not help identify when a change is needed. That depends on feedback loops, a topic deserving its own treatment.
Furthermore, plasticity is difficult to quantify precisely. It depends on the context, the team, the tools and the nature of the system.
Model Plasticity is a useful concept for explaining engineering intuitions. It offers a vocabulary for evaluating approaches. It can help us elaborate when to do upfront design and when to dive directly into code.
Looking ahead
This post introduces the idea of model plasticity and outlines why it matters. In future work, I will explore two related concepts: feedback loops, which determine how quickly we discover the need for change, and mistake rates, or how many attempts developers or agents require to implement a change. Combining these ideas will help us reason about the software development life cycle.
Further down the line the definition of plasticity should be revisited and perhaps it would be useful formulating a variation that focuses on model intrinsic factors.