Feedback is Control

Feedback is at the heart of Extreme Programming (XP) and XP is at the heart of agile DevOps. So, what is feedback?

The easiest way to illustrate feedback is to describe the skill of riding a bicycle. When we hop on a bicycle, our sense of balance immediately detects that we are losing our balance. We may start to fall on the right, and to prevent that fall we must ‘feed’ the system in the same direction. We immediately turn bike’s handlebars to the right in order to “catch” our fall. This is called ‘positive feedback’.

Why the need for control?

The usefulness of feedback is easy to illustrate when analyzing linear systems (such as riding a bicycle). Software systems, however, are anything but linear. Even the simplest apps are complicated enough to provide us with considerable challenge when attempting to analyze and grok them.

Non-linear systems need to be controlled (or else they snowball and fall in the realm of Chaos Theory, and we don’t want to go there).

How to control non-linear systems?

It is easy to see how software can control hardware, but a bit less plainly obvious how can software control software. In order to use software to control software, we need automated tests. These tests ensure that the input into the system never falls outside of the system’s domain.

We must write an automated test before we take our first step toward creating a system of automation. The automated test specifies the domain input values into the proposed system. Once we satisfy that specification (i.e. the expectation of what the domain input values are), we proceed to specify domain input values that are outside of the domain. We then ‘train’ (i.e. control) the system to reject invalid input. We do these controlling steps by following the ZOMBIES methodology (Zero, One, Many, Boundaries, Interface, Exceptional behaviour, Simple scenarios, simple solutions).

The above automated tests are called Programmer Tests, or Developer Tests. Each test sends a fixed message to the automated system and verifies that the system returns predicted answer. If the system does not return predicted answer, the test fails. Extremely straightforward, extremely deterministic (hence the name Extreme Programming).

A failure of a Programmer Test implicates only one unit. Developers should know exactly where to search to find the bug. Also, the failure of the test implicates only the most recent edit.

This situation in turn implies that developers can always save time (i.e. avoid debugging) by reverting that last edit. Extremely simple, and saves a lot of time.

Where does the control part enter the picture? By crafting an automated system following the above approach, we leverage those automated tests to permit easy and quick code changes. When making changes without having any automated feedback in place, we lose control over the quality of our system.

Assembling a system without getting an almost immediate feedback is similar to assembling IKEA furniture in a dark room. We are working blindly, following our sense of touch. Later, when we turn the lights on, we get a delayed feedback – we can see how crooked and mismatched parts of the furniture we put together are. Late feedback implies difficult, expensive changes. Which is why we do our best to avoid waterfall approach.

Strong immediate feedback gives us full control over the quality of the system we are building.

Other applications of feedback

Switching focus from hard core software engineering to software development process, we can examine some XP rules. One hard and fast XP rule states that a team cannot sign up for more work in an iteration than they did in the previous iteration.

Knowing how much work the team did in the previous iteration is an immediate feedback that prevents us from assuming that the next iteration will go substantially better than last iteration. Because it probably won’t.

One can object by saying that the things that kept the team from doing an ideal two weeks work in the real two weeks last time (things like server crash, someone’s sick days, someone’s unplanned leave of absence, etc.) won’t happen in the upcoming two weeks. But we pretty much know that something else will happen and it will interfere with our ideal work schedule.

We see that when making estimates, immediate feedback provides us with good control. Not having that feedback leaves us vulnerable to adopting wild guesses.

Also, Scrum Process (also known as Empirical Process). Scrum is the opposite of Defined Process, because Scrum does not depend on phases, handoffs and sign-offs.

Scrum is based on categorizing observed inputs and outputs and defining controls that cause them to occur. Scrum also prescribes the bounds within which empirical observations occur. As such, Scrum is also based on controlling the process via feedback (in Scrum feedback is called Inspect and Adapt cycle).