Last of the First

And with this we finally get to the "last of the first posts", after which I will fall into the actual pattern of blogging, rather than blogging about blogging.

Warning: This gets technical. No hard feelings if you skip over this post and read the TL;DR.

The purpose of this particular blog post is to explain the name of the blog. I'd hope that it was odd enough that it at least garnered a bit of curiosity from you, by this point. And more than that, I hope that the explanation makes a bit of appropriate sense for down the line.

\begin{engineering_lesson}
So, I've alluded to the fact that I'm an engineer by profession. When you're looking at controlling a system, or optimizing something, you have the choice of two extremes. You can have a centralized controller that is responsible for making the decisions for everything that happens in the system. On the other side of the coin, you can have an entirely decentralized strategy, where each individual part of the system (down to some level) is making independent decisions based on what that piece can sense.

You can also do some blending of the two, to get the best of both worlds, if you know what you are doing.
\end{engineering_lesson}

What does this mean?
This means that in the first case (Centralized) you have one "thing" that is making all the decisions for every part of your system. This means that the right hand always knows what the left hand is doing, because the brain is controlling it [Central nervous system and all that]. This is a very very good thing if you have a controller that is good enough at processing to make this happen. You can get some very impressive results. But... (and yes, there is always a but), you have a choke point in your system. You have a single controller that is:
- Obtaining all the information about the entire system at once
- Doing all the processing
- Communicating to every piece of the system what it is supposed to do
This leads to some obvious technical requirements.
-Your controller needs enough incoming communication bandwidth to receive all the necessary information.
- It needs enough processor power to be able to take all of that information, make sense of it, and figure out what each piece of the system needs to do to get the desired results.
- It needs enough outgoing communication bandwidth to send all necessary information to each piece of the system.
- It needs to not fail, because if failure occurs at the central controller (or its communication points), then the system is without a head. Total system failure is expected.

You can notice here that there are some analogies to biological systems. You have a central nervous system that senses and controls (almost) every action you take.
These kinds of strategies are used pretty often in an engineering setting as well. Assuming your problem is simple enough and your controller is robust enough, then this is a very good solution.
This is also used in some kinds of organizations (or situations pretty close to a centralized controller). I have been in some EVE fleets that have functioned very much like this. We'll touch back on this later.

For the second case (Decentralized), you have a bunch of separate "things" that are each taking in the information available to them, and making decisions based on what they can sense, and what options are available to them. You can start to see that this is the exact opposite of the centralized scheme. So each "thing" (let's call a "thing" an agent) is responsible for:
- Obtaining as much information as is available to it
- Doing some processing using that information
- Deciding what its best action (if any) is to take
In the purest sense, no communication between the agents is necessary for some coordination to appear.
This leads to some different technical requirements.
- Each agent needs some way of sensing whatever it can
- Each agent needs some kind of processing power
- Each agent needs to take the "best action" that it can to help the system get the desired results
- Agent failure leads to some decay of system performance, but isn't catastrophic

Now, this is entirely opposite of the centralized scheme. But it is pretty important to notice that this one also bears some similarities to some biological systems. Look at an ant colony: each ant goes about its business, and the colony survives without the need for meetings to make sure that each ant is caught up on the comings and goings of the other ants.
Likewise, look at a termite colony. The towers are impressive, to say the least. And these termites are blind. How do they do this? Well, I guarantee that there isn't an architect termite that is drafting up plans and directing the workers around. They just follow a set of very simple rules, and the results speak for themselves. They simply put the building material near other freshly deposited material. This forms a pile. Piles start to form small spires. These spires join to form arches. Arches join with arches. Floors are formed. And then all of a sudden, the simple rules are starting to make something not so simple. An Emergent Structure starts to form.

I've also been a part of EVE fleets that have been run like this, where each pilot is making their own decisions, and just using comms to inform the other pilots about what they are doing. No one is directing the whole scheme, but the interceptor pilots are tackling, the EWAR pilots are ewarring, the logistics pilots are keeping ships up, and the damage pilots are picking off easy targets.

But... (and again, there is always a but) the right hand can not know what the left hand is doing. It is possible that agents can be (intentionally or not) working against the interests of other agents. Remember playing basketball in elementary school? Remember the kid that was the ballhog? The actions he was taking (which I'm sure he meant the best with) were hurting the team overall. Same story here, but in a very different setting. How do you get around this? Well, that's not an easy question to answer, and that's why I have a job in real life ;-). Suffice for now to say that as long as you zoom out far enough to look at the longer term results, you can start to figure out which actions were good and which actions were bad.

So how does this all relate to this blog?
Well, first of all, it's a glimpse into what I do with my everyday, which affects the way that I look at problems. Second of all, the concept of emergent structures will pop up again and again through this blog, whether I specifically call it out or not. None of the ways that I go about looking at a situation involve any black magic or voodoo. It is always just taking the problem, breaking it down to its most basic, and then figuring out how to solve each individual problem. I do the same thing whether I'm looking at the market, or looking at a ship fitting, or looking at a fleet engagement.

It's okay if you don't quite get what I am saying here, yet. If you did, then I'd have awfully little to write about, wouldn't I? If you managed to get through this far, then I do thank you for your patience with Russian novels.

TL;DR:
Simple rules, impressive results: Emergent Structure.

Next we will, in fact, go into a ShipStudy of the Drake. What makes it so popular? What settings does it work well in? What do you need on it when you fit it? What are the misconceptions? How can we use those to our benefit?

-K'