A Short History Of Feedback

How the concept of feedback returns and returns over 400 years, and how every time it's a "reinvention".

Ok, so in the next 6 minutes I am going to give you a four-hundred year history of the idea of feedback, as it pertains to software development.

Obviously, this is a long period of time, we’re not going to mess around with detail, so strap in!

This is Cornelis Drebbel, a Dutch Inventor who lived in England around 1620. As well as building the first navigable submarine, discovering a scarlet dye and draining the moors of Cambridge, he invented a mercury thermometer-based thermostat to regulate the temperature of a chicken egg incubator.

As the incubator temperature rose, the mercury rose too, and this controlled the amount of fuel provided to the heater for the incubator.

This is probably the first example of a man-made thermostat, which is a feedback loop.

In 1788 James Watt and Matthew Boulton created what’s called the “Rotative Beam Engine” - a type of steam engine, which was used for driving a metal polishing machine.

It was the first to be fitted with a device called a “Governor”, which is what feedback loops were called back in the 1700’s.

The black arrow on the diagram is pointing to the governor.

This is a clearer picture of the governor mechanism.

So, the idea is that the steam drives this wheel at the bottom. If there is more steam, then the wheel will go faster.

However, as the wheel turns faster, these balls fly out to the sides, which has the effect of moving the control rod up and down, controlling the valve of the fuel pipe.

Faster spinning, less fuel, slower spinning, more fuel.

This is one of the first amplifiers, from 1912, using valves. Amplifiers used to distort really badly, but in 1934 Harold Black developed Negative Feedback - feeding back part of the output signal back into the input, but reversed, to lower its level.

So, a high output will reduce the next bit of input - almost exactly like a thermostat, but for sound.

In 1940, the discipline of Cybernetics was founded. One of the core concepts of this is the feedback loop, but the discipline is all about regulatory and control systems.

Interestingly, the word “Cybernetics” has it’s roots in “Kubernetes”, which is the Greek Word for the helmsman of a ship.

In the 1960’s the discipline of Cybernetics was reaching peak popularity, and Doctor Who picked up on this to create their legendary “Cybermen” for Doctor Who to fight.

Going back to the 1940’s again, these guys, McCulloch and Pitts were looking at trying to build artificial neurons - the precursor to todays Machine Learning algorithms.

But it took until this guy, Frank Rosenblatt to add a feedback loop. The feedback loops these guys were playing with were basically an early form of Back Propagation- which is the algorithm we use to train neural nets with.

That is, you compare the expected output with the actual output, and adjust your model slightly, so that next time you run it, the actual output is closer to the expected one.

So, machine learning is basically via a feedback loop.

By the 1960’s Chaos Theory was getting started. It looked at the power of feedback loops and the way that in some systems, they created control, but in others, they created unpredictable behaviour.

In 1980, Benoit Mandelbrot created the Mandelbrot Set, shown above, which is an example of a simple function applied over and over again on itself in a feedback loop.

To understand how this is drawn, you have to imagine each pixel of the image is a different two-dimensional number. You apply the Mandelbrot function to this number and iterate. If it iterates to zero, you get black. Where it spirals off to infinity, you get a colour.

In this diagram, a deep blue means it spiralled off faster.

Going back slightly, in the 1940’s a guy called W. Edwards Deming was using statistical methods in process control. These didn’t really take off in his native America, but he went to Occupied Japan after the war.

His ideas about process control and monitoring were eagerly adopted by Japanese manufacturers like Sony, Toyota and so on.

This is his “Plan Do Check Act” cycle, which hopefully guides you towards building high-quality manufactured goods through measurement and adjustment.

Again, another loop.

Over the 1960’s and 1970’s there were various “Quality Gurus” who defined what quality manufacturing processes looked like.

They introduced ideas like “Root Cause Analysis” and “Fishbone Diagrams”, “Quality Assurance” and “Zero Defects” into the manufacturing lexicon.

A lot of them worked on what is called the “Toyota Production System” which became the model of how to produce cars, and led to Ford and General Motors wanting to come and find out how the Japanese were setting up their assembly lines.

One of the key ideas of Japanese manufacturing was “Just in Time” that is - building things quickly to order. It’s from this we get the idea of “Kanban”, which you are probably familiar with.

In 1988 the Toyota Production System, and the various ideas around it kind of got rebranded to “Lean”, and lots of manufacturers started applying “Lean” and “Just In Time” techniques to make their processes more reliable and faster.

Also in the late 80’s this quality thing was really popular, and there was something called six-sigma, which you might have heard of, which is kind of just the Deming Cycle feedback loop all over again.

And then there was this thing called ISO 9000 which is still going strong which is basically takes this idea of quality and adds a lot of bureaucracy and a certification process.

Businesses used to use ISO certification to say “we really care about quality” but one criticism is that it burdened them with so much bureaucracy that it hindered productivity.

OK, last bit. Coming into the early 2000’s the whole Agile movement in Software was all about incorporating more feedback loops.

By breaking down delivery into small parts, you get to have a feedback loop between the releases.

Obviously, this is heavily influenced by all that work in Japan that we talked about a couple of slides back.

And, this book about Lean Software Development is based on the Lean Manufacturing system.

So, this is one variant of a diagram you find all over the Internet which is the Scrum feedback loops model. There are two main feedback loops in Scrum - a daily standup (that purple one at the top) and then a plan / implement / review / retrospective loop which happens based on the period of your sprint, so likely every two weeks.

So really, this model is harking back to Deming’s model in 1959 - it’s nothing new.

So, there you go. Four hundred years of people discovering and rediscovering feedback loops and applying them to their own domains.

In a way it kind of seems surprising that this keeps happening! Human learning is clearly mostly feedback-oriented. You try something, you see what happens, you adjust your model of the world, you try something else.

It’s not surprising that lots of our machine learning algorithms work in the same way.

What is surprising, I think, is the level of re-invention. Broken down, whether it’s thermostats, amplifiers, perceptrons, manufacturing processes or babies, it basically comes down to this.

You have a subject, which you observe and interact with. This allows you to develop and improve your Internal Model of reality. In the case of a thermostat, this is just: desired temperature and the temperature you think it is.

Then you take action, and the subject changes. Which causes you to update your internal model.

Thinking about this in terms of Risk Management, you have your Internal Model of reality, which alerts you to certain risks. So, you take action on those risks, and the world changes.

This changes your Internal Model, and hopefully this is how we expose those “unknown unknowns” we talked about before.

Then you can act again… and so on.

So, Scrum mandates two key feedback loops. However, there are lots, and a good strategy is to use as many as you can and look for more all the time.

Bug reports are slow to come in, and arrive only a while after people have been using the software. So, these are a long feedback loop.

Whereas Unit Tests run frequently, so the feedback loop is short.

But the Bug Reports are telling you something about the real world, that you don’t get from the Unit Test results.

Let’s think about automated builds. If we just compile our code, the feedback loop is short. We’re at the bottom right. But then if we add some tests, we move up and to the left, since the tests take time to run.

We kind of get to choose where on this curve our feedback loop operates. Sometimes we want fast feedback, sometimes we want to sacrifice speed for quality.

But imagine for a second that you had a special time-travelling machine. With it, you could make a change to your software, and get back a report from the future listing out all the issues people had faced using it over its lifetime, instantly.

If you had that, you wouldn’t need a compiler anymore, would you? You’d have something way out up and to the right of this “useful frontier” line.

And that would be a huge advance.

As a developer, I am always trying to push my feedback loops up and to the right. For example, I’ve watched people who change a line of code, run a complete build, deploy some software and then test out their one line code change.

This is awful. They’re operating way below the curve here. If I find myself in that place, I’m always looking for the shortcut so I can get back to the frontier and test my code more quickly, usually by taking some shortcut or other.

So, that’s really the summary of this section.

Don’t get bamboozled by new methodologies or buzzwords: Test-Driven Development, DevOps, Agile, Kanban, ISO9000 whatever.

At the heart of all of them is people uncovering and exploiting feedback loops in slightly different ways.

And then probably trying to sell those ideas to you and make a lot of money on certification courses.

Let’s move on.

Made with Keynote Extractor.