Testing in a Complex setting - The link between system thinking and Software development

PLEASE NOTE that this article is under construction, please feel free to comment on any reaction you might have if you dare to read any of it. It will continually be updated and added to.

A system is defined as: a regularly interacting or interdependent group of items forming a unified whole – Merriam Webster Dictionary

However, depending on how the system is assembled with regards to “items” and their “interactions” a system can be characterized by a certain level of complexity. Kenneth Boulding, an professor within economy and systems theory origin from UK and Oxford, presented this model below where the lowest levels of complexity a system can have is a mechanical system of any sort. Above that mechanical level from a complexity aspect is a system with feedback-mechanism to become self-regulating. After this there is biological systems, in its nature self-regulating, even self-healing in various aspects. And what can constitute as a perfect example of a known complex biological system than us, human beings - consisting of approximately 78 organs, 650 muscles connected through 187 joints and 206 bones all working together as a whole thanks to 11 vital sub-systems where circulatory, respiratory, nervous, and digestive systems to just mention a few of them. This is vital to understand in systems theory, a system often consist of many layers of sub-systems.

When we develop IT-solutions it is crucial to understand that we are dealing with all these levels of complexity at the same time, in parallel. All the way from the very simplistically mechanical (source code for example) towards the biological (users or AI components) and even the most complex levels where we end up impacting our society and climate (long term effects on usage). The needs of the society in terms of IT solutions are today definitely not one-service-fits-all. The needs require to be met on an individual level, to be inclusive and constantly transformed to meet upcoming needs in an ever-shifting world with climate changes, political, cultural, technological transformations all around us.

A model often referred to in agile development circles is the Cynefin model. It divides various problem that we encounter in four different domains: Clear, Complicated, Complex and Chaos. The model even assists in explaining how to approach these different domains in suitable manner.

This model is widely used and referred to due to this fact, that it explains on a deeper level how we must alter our thinking and actions depending on the nature of the problem we face. The problem with this model however is that it leads us to think that a scenario can only stay in one domain at a time, and that our job is to keep reducing the level of complexity, so we keep the problem in the simple and complicated domains. This approach of trying to reduce the level of complexity in a phenomena to simple terms is defined as reductionism. This right-hand side of this model are the deterministic domains where we can feel the comfort of knowing that if we just follow a plan or a recipe – we will reach our target state in the end. But we often try to lure ourselves.

Because, when dealing with software development, we are dealing with these problem categories – all at the same time. When altering a condition or a variable in the source code, this is a simple operation, but that change can interfere with another system in the integrated system landscape, causing a possible database timeout. This, on the other hand will cause a customer or a user to get incomplete or even incorrect data to base their actions on, causing in best case discomfort, or in worst case scenario – death or worse types of catastrophic effects.

To learn and understand these types of causation, or butterfly effects, is crucial in sustainable system development in today′s ever-changing digital world. However, it requires a lot from us. It requires us to be willing to see and embrace the bigger picture, the holistic perspective of what we are acting upon, and it require is to reduce the number of reductive initiatives that is being set up as an instinctive reaction to the ever-increasing complexity. I often use these types of models below to explain the system development task in a better way. The model refers originally on how to perceive a child′s maturity in life, how the child learns new things, embraces more and more perspective to understand the causation and correlation between action and effect on various domains, that increase in complexity the further away you get from us. ??

?The main strength of this model is that it helps people understand what is wrong with reductivism, it is just as trying to say to a person that they shouldn′t bother about world peace, or climate change, it doesn′t matter to us, let the politicians take care of that. To say things like:

·???????? We can′t let the development team handle cyber security, it is to difficult for them.

·???????? We don′t want the supplier to engage in system testing due to the fact that it is not in their scope.

·???????? Don′t bother about prioritization of requirements in the backlog, they’ll handle this in the portfolio teams.

It is not truly helpful when trying to ease the burden of a development team by blocking out the numbers of necessary perspectives for them. Not in the long run, it might be a intermittent way of handling the current situation, but in the long run it is crucial for any development team to own the entire spectra of various perspectives in life, as well as development.

Because the opposite approach - centralization of knowledge, power and steering is not the way to go. The increased complexity creates the needs of huge variety, the possible way to come up with a solution is also of course of huge variety. So this needs to be met in the other way around, using for example a federated, or a distributed model consisting of autonomous teams acting on a common social code of conduct. You could say that if our assignment includes a high degree of variety - this needs to be addressed with same level of variety. This is the fundamental idea of where "being agile" comes from. This means for the development teams:

• Processes and roles will decrease in importance
• Interest in holistic views on what value really means increases
• Inventing "someone else's wheel" gets more frequent
• Searching for causation and discussions on correlation gets more frequent
• ....in short, increased maneuverability and joy of creation for the co-workers closest to customer (and code).