Systems theory is about what happens when individual items are connected and become a system. “Items” in this context can be anything physical and/or abstract, which gives you a pretty huge scope. Systems are ubiquitous. Examples include mechanical systems such as vehicles; social systems such as organisations or countries; and logical systems, such as software. Many of these systems can cause disasters when they fail, as in the examples of nuclear power plant safety systems or autopilot systems in aircraft; systems are important.
There are regularities in how systems behave, and some of those regularities are both counter-intuitive and extremely important. That’s a potentially dangerous combination.
If you understand systems theory, then the world makes a lot more sense, particularly if you combine it with game theory, which will be the topic of one of my next articles. Most questions that start with “Why don’t they…?” can be answered either with “Resources” or “Systems theory” or “Game theory”.
In this article, I’ll look at some core concepts from systems theory.
He cried in a whisper at some image, at some vision,–he cried out twice, a cry that was no more than a breath–
“‘The horror! The horror!’
This article is one in a series about the problem of identifying and clarifying client requirements, using the ongoing semi-humorous example of a client’s requirement for an image of an elephant. The previous episodes have looked at some bad ways of tackling the problem. This episode looks at methods for tackling difficult areas of requirements gathering, where people are for various reasons reluctant to talk about a particular topic. It also looks at the underlying reasons for that reluctance.
That takes us into some uncomfortable and morally ambiguous territory, which is why I’ve opened with a quote from Heart of Darkness. If you’re trying to fix real problems, then you need to know how to find out the realities, and that isn’t always fun.