Cybernetics and software processes

Posted on January 18, 2008
Filed Under Computing & Software Systems | Leave a Comment

How might control systems theory, at the heart of cybernetics, inform the way we develop software? Well, cybernetics can be brought into play at 3 different levels:

Borrowing from cybernetics

Why would we want to borrow ideas from the world of cybernetics and control systems and bring them into the domain of software? Well for one thing, those domains deal with variability, something that modern / complex software systems have to deal with all the time.

Excecution-level control

At the execution-level, in spite of best practices and well-published software patterns and micro-architectures, it is still easy to write software with tightly coupled components. We can have rigid interfaces that cannot cope with any variation in transactions, and we can have components that can fall over and die without any of their peers knowing. Over time, such software generally transitions (if it’s well looked after) into a collection of ‘metasystems’ of components, each with it’s own controller (eg a manager class). This is the level at which we normally accept control theory into the domain of software. But what about the higher levels of the software system, or the entire development project itself?

Test-level control systems.

Based on the principle of selective variation, when conditions are favorable we need less variation in a system, as all outcomes are likely to succeed/survive. In unfavorable conditions however, a system needs to give itself options. It needs to be more willing to ‘try anything’ – in the hopes that one of the outcomes will be the one to help it survive.

Now think of a test harness as a controller in a negative feedback system with a piece of software. ‘Favorable conditions’ for a test harness are ones where the application under test is dying. Once such points of weakness are found, the test harness best serves the goal of testing by focusing (narrowing) its efforts – it should hone in on the areas of the application that demonstrate the most weakness.

In ‘unfavorable’ conditions, where the application under test presents only a few failures, or they are scattered randomly throughout the application, the test harness needs to try harder. It needs to exert itself, and creatively. It needs to run a whole gamut of test cases that touch several different parts of the application in order to ensure that it finds a failure or a weak spot.

These types of adaptations should lead to greater efficiency in QA cycles.

Process-Level control

What if we were to build software in a way that changed over time?

We’ve all heard of different meta-processes like CMM and ISO, or methodologies like Agile and XP, or even international process assessment frameworks like SPICE. These  imply that the process or methodology is the ‘controller’ for the system under development, yet there is little discussion of how feedback from the system under development is dealt with by the controller itself (the process). As result, we rarely adapt our methodologies to suit the system being built. We *do* alter or trim down processes (eg cut down on paperwork) based on feedback from the humans in the system – but they are only part of the system; however the properties/behaviour of what is being built can also be taken into account.

The system being developed can ‘feedback’ to the control system by: revealing hidden complexity, being resource-intensive (eg bandwidth or data-intensive), needing more or needing less human oversight; by failing a lot, by being buildable or not, testable or not, release-able or not.

In turn, the control system may adapt by changing the roles of the people on the project, adding or omitting steps in the chosen methodology, adopting a different methodology, changing quality gates and/or testing levels, refining change request policies and so on.
For this type of ‘negative feedback’ dynamic to work, software projects need to be approached as entities in their own right: goals with respect to development need to be quantified so that the ‘control system’ can detect divergence and correct for it. Eg: “Module X is turning out to be way more complex than we thought. Lets create a special X team to redefine and build X using a different process from the rest of us.”

Such an approach would allow a team to adapt their processes to fit the evolution of their software product.

Tenuously Linked (blame my tagging):

Comments

Leave a Reply