I have a habit of going down rabbit holes. I saw a reddit post about observability in software engineering and in skimming the topic, another topic came up: "control theory." So instead of finishing reading the article I found on observability, I went on to skim another new thing. And something immediately caught my interest. In mechanical systems, there is an entire practice of having a desired output, and forcing a system to correct to to that output based on the actual output. In high level software systems, if you desire an output and get something else, trying to correct that output after the fact is extremely frowned upon at best. Imagine making an HTTP request to a web server and having it crash. Now imagine on a failed HTTP response, automatically ssh'ing to that server's host to reboot it until the HTTP request came back with a valid response. This would fix the issue of not being able to get back HTTP responses from the server. It would also get the implementer immediately fired. In software, undesired outputs need to be investigated and fixed from an underlying root cause. I wanted to know why an idea pervasive to mechanical systems is at best verboten in software systems. [So I googled and found a document from the University of Michigan about how control theory has been used in computer systems.](https://www.eecs.umich.edu/courses/eecs571/reading/control-to-computer-zaher.pdf)It looked like it had promising answers to my questions. Each example in the paper had several commonalities that made them differ from my http example: - The controlled outputs were by definition, always numerical, measurable, and able to be adjusted analytically. This differs from the "pass/fail" nature of my desired HTTP output (maybe I should have suspected this to be the case on my initial skims from seeing "value" used more often than "output"). - The controlled values were closer to a technical requirement valued by an implementing engineer than a functional requirement valued by an end user. If I am making an HTTP request to a server, I'm not worried about something like the CPU utilization or the size of a memory page in the hardware I'm contacting. - The controlled value is impossible or undesirable to directly change. If I have a connection count that is a function of the number of users accessing my system, I don't want to manage it by asking users to coordinate with each other when they're connecting to my system. I very rarely if ever deal with outputs and values of this nature, which is probably why I have only heard the term "control theory" in passing. Most investigations don't end in life changing conclusions, but the diversity of thought they bring is worthwhile in and of itself. Now, two weeks later, I can get back on track to learning about observability. <font size=1>Published 2024-05-21</font>