Last time we started to explore the idea that you can have a system or problem that is difficult to deal with and understand because the interactions between blobs are in some way difficult. However, we only covered the idea that the arrows that connect blobs are complicated. There is a similar problem when we consider overlapping blobs, which can arise from multiple arrows coming and going from a single location.
The initial diagrams we dealt with only had a single initial blob and a single final blob with one arrow connecting the two (like the one on the left). This is an ideal situation to start with because it allows you to explore a lot of aspects that can make a problem difficult on an individual aspect by aspect basis.
However, quite often problems in the real world are much more complex. Previously, we saw that multiple arrows could create a difficult problem, but what happens to the blobs themselves when multiple arrows are present.
In the next diagram we see a single blob that can transition to one of two choices. However, what that really looks like is two separate valid input blobs that each transition to a different output blob. Conceptually we think of the initial blob as a single starting point. In reality each transition has different rules and assumptions built into them and we can get a scenario where the valid input blob is not the same for each transition.
There are two more possibilities for overlapping blobs.
The first one is where an output blob overlaps with a valid input blob. This scenario happens when the first transition can create values that are not valid for the second transition. This is also a good example of why we want our transitions to be continuous. A continuous transition can simply stick with values that we know will land us in the middle of the intersection of output blob and valid input blob. However, with a discontinuous transition, you must meticulously check each input value of the transition to make sure that the output will not land in an invalid region of the next transition.
The second one is where one blob is the destination for two different transitions. In this case you can end up with overlapping output blobs. This isn’t necessarily problematic if this is a final blob, but if you intend to use the resulting value in a new transition then it might be difficult to know when the system is going to continue functioning in a healthy way. It may look like you have a valid object, but depending on how you got that object continuing to use it may result in invalid behavior. Even worse is when this only happens some of the time.
We have three possible overlapping blob scenarios: When a blob has two or more outgoing transitions, when a blob has two or more incoming transitions, and when a blob has an incoming transition and an outgoing transition. There can also be blobs that have a transition that starts and ends with the same blob, but this can be thought of as a combination of incoming and outgoing transition.
In an ideal world, all overlapping blobs would be completely identical. This is beneficial because it means you can conceptualize the blob as just one blob. Once you understand the system in terms of that blob, you shouldn’t expect any additional problems to crop up for that area of the system. When the overlapping blobs are different, you encounter additional problems because you have to know what path you took to get to your current location. Systems that appear to be functioning correctly can suddenly grind to a halt because a new transition was added in a way that doesn’t fit well. Finding a way to understand what’s going on can be very difficult.
Things can become arbitrarily difficult when dealing with overlapping blobs.
Blobs that overlap perfectly make a problem easier to deal with because there’s only one way you have to understand the system at any given point. Imperfect overlaps are hard to form intuitions for because you can easily end up with seemingly identical scenarios which nevertheless sometimes work fine and sometimes break everything.
Next we are going to transition away from talking about the aspects of a problem that can be difficult to deal with and instead talk about how the features in programming languages as well as the structures in code itself can be difficult to deal with.