03 Change Driven Design, 03 The Change Factor

Separation of Cause: Fallacies of our Designing Minds

Reading Time: 7 minutes

In the previous chapter we’ve seen the problem caused by a misalignment of an application’s design with the Change Stream. A single Product-related Change can cut through our entire application, which has the potential to cause Instabilities and unintended Changes to other products. To resolve this, we refactor our applications.

We’ve also seen the problem caused when an organization is misaligned with the Change Stream. It causes frictions which are Inefficiencies. To resolve this, organizations are being refactored, better known as reorganizations.

We’ve seen the Engineer’s and the Architect’s roles in this, and we’ve seen that with their best efforts they may not be able to withstand the unsteadiness of the Change Stream. As the company grows from one stage to another, its goals are Changing. This sometimes entails another reorganization that entails another refactor to our application.

We’ve already resolved the above problem, only in a smaller resolution of a single Module in our fifth chapter of Exclusivity of Change. We came up with a principle called mutual exclusivity of Causes and Directions of Change. In this chapter, we’re going to extend this principle to better fit the entirety of our application as a step towards reusing it to resolve our big problems.

Sense of Direction

We’d start with an example out of Silo’s physical device (2020, manufacturing of a connected/smart vacuum sealer). It would make an interesting one as I guess most readers are less familiar with hardware. I’d like to leverage our preconception about it, that it is hard and more limited than software.

Silo’s device had about 10 controllable physical mechanisms, such as a pump. Product-wise, it also had an experience where the pump was switched on and off.

We wish to design our application, divide/group it into Modules. Obviously, a relationship exists between the hardware and the application. Let’s try to define it via Causes and Directions of Change, where a closed set of Causes have to be mutually exclusive from the rest of the Causes. 

Hardware for our application is similar to a dependency on a 3rd party. Obviously, replacing the pump is a hardware Change. We have several hardware physical elements grouped together, so a closed set of Causes exist. They also all originate from a clear cut of the Source, the hardware/mechanical engineer (are we sure it’s the Source?). The conditions exist for a mutually exclusive Direction of Change. In order to determine they are indeed mutually exclusive, we need to find the opposite of it. And what is the opposite of hardware? Software!

W-R-O-N-G! We have fallen to another trap of our binary thinking minds, a false dichotomy caused by our very own vocabulary. To prove us wrong, let’s ask ourselves “then what about a driver?”. It is a software located inside the hardware. If the driver Changes due to an update, is it a hardware Cause or a software Cause? It is extremely arguable, but the answer can not be both as it is contradictory to our wishes for them to be mutually exclusive.

It was the wrong question that has led us to an incorrect conclusion. It’s not what is opposite to hardware, it is what is complementary to Hardware. And that is Non-Hardware, everything else in the world that is not Hardware. Now we can really be sure we have two Directions of Change that are really mutually exclusive. 

Mutual exclusivity of Direction and Causes define the relationship between the two. Non-Hardware Modules would be using the Hardware Modules. Thus they need to be encapsulated and an integration point is needed (API).

Sense of Cause

We can put the mutual exclusivity that we had defined to a test. We can come up with many Hardware Changes and Causes and see if it holds, even ridiculous ones. Looking for failures is also a way to find more Causes, and design with Eventualism leads to finding them.

The first and most basic Hardware Change would be someone replacing the pump with a different pump model. The Direction of Change would be from left-to-right. Same as if someone adds a fan, an LCD screen or a speaker for some reason.

On the contrary, blinking LED 1 instead of LED2 while the pump is on is a Change to the device’s experience. By definition, there is no Hardware Change thus it can not be a Hardware Cause. As such, the Direction can not be from left-to-right. As there is no other option, it would be from right-to-left and a Change to experience fits the definition of a Non-Hardware Cause. It fits.

Which makes me wonder. Could this entire mischievous discussion could have been avoided, if we’d just simply named it differently? Such as the Physical v.s. Non-Physical tuple? Honestly, I don’t know. But it goes to say how naming has much more effect than just mere wordplay. 

Okay, but let’s say that the new experience requires a new LED light. Well, tough luck it’s impossible. The device would already be at our customer’s homes. We won’t be able to send a technician to each and every customer. It is beyond our reach. It would have to wait for version 2.0 of the device to be manufactured in the factory. When that happens it would be a Hardware Cause and it would follow its Direction.

Okay, but what about a button? It is not being used by the application, it triggers it and the entire experience! Sounds like it contradicts our defined relationship. Technically speaking, when a button is pressed a “pressed event” is being broadcast. And a button is also Hardware, so addressing these events would be a Hardware Cause. If we’d follow its Direction from left-to-right it would entail a Change to the integration, where the Change should stop. If the application would like to consume this event and create an experience out of it, that would be a second Change in the right-to-left Direction. Even when a Change beyond what is needed, the mutual exclusivity still holds.

Okay, but what about the driver? Whether we knew of or not, we still haven’t decided if it’s Hardware or Non-Hardware. The answer is, it doesn’t matter. That would still be one Change coming through one Direction, one Change at a time. Two small Changes instead of one Big Change.

Unlike when we first came up with the mutual exclusivity principle, this time we named the exclusivity first and only then looked for Causes and Sources. In both cases, we ended up with two mutually exclusive clusters of Causes, where no Cause can be in both. That entailed the mutually exclusive Directions. We can of course first cluster the Causes and only then name the mutual exclusivity. Honestly, although sometimes doable that would be much harder to do. Cross validation would ease it up a bit.

Sense of Control

Let’s take advantage of the fact that Cause is the immediate Event prior to Change to come up with another way to reach and test mutual exclusivity of Causes.

Let’s go back to the example of adding a new hardware LED. For Silo, it was impossible to do once the devices were at the customer’s homes. Changing the hardware was beyond the company’s reach, it can only be done in the factory. Which is also beyond the reach of our mechanical/hardware engineer. Which makes it even further beyond the reach of our software engineer. Neither of them can just wake up one day and just add an LED on the spot. Should make us wonder whether the Source is the factory or the mechanical engineer.

On the contrary, changing the experience of the device is within a closer reach, quite immediate and almost entirely within our control. The PM, the CEO, any Engineer can wake up one morning and decide that the LED blinks or not. Our control and decision to do so is limited by the existence or lack of an LED.

In this chapter, hardware was real for Silo. For other cases, it is a metaphor with a principle that holds. Our iPhone’s camera is beyond our reach, but to develop a mobile application that uses that camera is within our control. Integrating with a 3rd party provider, such as Stripe, is within our reach and control. Asking Stripe to Change their API, is a little within our reach and out of our control.

In the next chapter, we’ll be leaving hardware behind and we would deal with pure software applications. We would be maintaining the very same principle of “This” v.s. “Non-This” mutually exclusive clusters and come up with more left-to-right v.s. right-to-left mutually exclusive Directions.

Leave a Reply