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.

Software systems lifecycle. (Described in prose below)

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:

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.