Secret Life of Systems
Software systems aim to solve real world problems. They implement some behavior that the authors of the system believe would address the problem.
For non-trivial systems the coupling is imperfect between the real world problem, the problem as understood by some group of people, the perceived solution, the solution as it is actually implemented, and the solution as received by the users.
The diagram below illustrates this phenomenon.
The software1 system life-cycle begins – as most things do – in the real world.
The Problem (P)
There is a problem that affects some group of people2. Let’s call it P.
We know these problems exist by their symptoms. For example people might just feel something isn’t pretty great or that things could be better if only we could figure out how.
Beyond that a precise and comprehensive definition of the problem doesn’t exist. This might seem like a strong claim, but it comes down to the fact that everything involving people is complicated.
The Model (M)
So people set out to understand the problem deeper. Experimentation, user studies, interviews, observations, are all things that we do to conjure these invisible problems into existence. We go probing for symptoms to understand what might be causing them.
Based on these we develop and a model of the problem. The model may be laid out for everone to see or it could be in someone’s head.
Let’s call this M for model. The model is the entirety of our understanding of the problem. It is a prerequisite before we can theorize about …
The Solution (S)
At first the solutions are themselves models – things that work in theory when evaluated against the model M, but yet to be verified against the real world problem P
The models of solutions – let’s call them S – are what we think will address what we assume is the problem. Depending on the level of rigor, we will draw little diagrams, write design documents, shop our ideas around, discuss alternatives, collaborate and refine these solutions.
Eventually or during this process we will put something together that works somewhat.
The Implementation (I)
So an implementation comes together – let’s call it I. The difference between S and I stems from practical matters. Time, resources, technical limitations, all affect how much of our model solution S we can implement. The result is often different from what we thought we would eventually have.
Deployment (D)
Whatever solution we put together is useless unless we take our masterpiece to those who are experiencing the problem – the users.
The likelihood of a non-trivial solution reaching its entire intended audience is low. The implementation may not be received in the same spirit in which it was built.
And often, this is the point at which we will find out how much our solution matches the needs of the real world.
They way in which our implementation I interacts with the real world is – the deployment D.
Much like the subject at hand, systems lifecycles don’t follow neatly delineated phases as described. Real systems typically exist in all phases simultaneously. Understanding the question is a continuous process. Plans change all the time. As any engineer will tell you, what tools and resources are available are also part of the problem statement.
But there are a few key observations that you can make from this model:
We lose information at every phase. Our model of the real world problem is guaranteed to be of much lower fidelity than the real thing3. Our model solution is going to fall short of addressing our model solution. Our implementation will not match our aspirational solution. And whatever we manage to get in users hands isn’t quite working the way we thought it would.
Understanding the problem is a continuous process. Every phase of this lifecycle brings with it new insights into what it is we want to achieve and what we are working with. Each new insight changes our problem statement, solution, and eventually implementation and deployment.
Understanding the problem must be deliberate. Given that the deployed solution isn’t quite a match for the real world problem, we need to ensure that we have the right measurements and probes in place to understand this mismatch – be it telemetry, user satisfaction surveys, interviews, or whatever else.
Whenever we are holding some concept, being conscious about where in the lifecycle that thing fits helps us get a sense for the level of maturity of the concept and where you need to be to solve the problem.