In the previous chapter, we’ve talked about how the Change Stream’s internal distribution continuously Changes in unpredictable ways. One day our application would be hit by Changes only to two independent Modules, and months afterwards suddenly would be hit with Changes to them both. And a week after it will cease. The Change Stream is unsteady.
We also talked a little about Changeability, techniques and designs to optimize applications for future Changes. We wish to achieve the same by getting to know the Change Stream better. To see if by digging deeper into it other solutions would come up, hopefully ones that can help us make our applications more agnostic to this unsteadiness.
We’ve seen a correlation between an application’s design and Intentions. We speculated that Intentions might be a fitting criteria for grouping Modules. In this chapter, as another step into the Change Stream, we’re going to talk about Intentions and the people who carry them through.
Tunnel Vision
[The following is based on a true story from my time at RapidAPI (2021). You can read further details and the actual work done in Waste Reduction: Unbundling chapter. Below is a very simplified and minified version of it.]
In our story our Engineer works for a company that has exactly 2 products, Product A and Product B. The company has a single application with two Modules mirroring them both. One day, someone in the Customer Service team opened a Bug Ticket titled “Customer X has been incorrectly charged for his subscription to Product A”. The day after, it Causes our Engineer to start exploring for the bug and to get it fixed.
Our Engineer reads the ticket’s details, an action setting his mind’s focus on Product A. It is a psychological effect called framing, which has set our Engineer’s Intention to Change Product A and it alone. It would be unfair to presume that Product B is actually visible or accessible to our Engineer. It might have been secretly developed on the other side of the world. But it is almost always his mind that hides the potential consequences to Product B.
As his mind is focused on Product A, our Engineer would first go through the code of Product A. He found the bug in Subscriptions, an area in the code his mind is blocked from seeing as an intersection shared with Product B. This along with his Intention set on Product A alone, he’d make a Change tightly coupled to Product A. It would result in a Change with a potential to introduce an Instability to Product B, either an immediate one or a future one. That is something to prevent.
In a far away office, the company’s Product Manager is managing both products. A Customer of Product A has asked for a new kind of subscription plan. Same as the effect on our Engineer, it has focused the PM’s mind on Product A. He made a Change only to its design as he had the Intention to affect Product A alone. The potential to cause an Instability has been created, because it might have broken some unknown alignments between the two products.
Our Engineer will follow the PM’s Intention, which is technically an impossible one. Subscriptions are in the intersection between the two products which would Change both products. If they both insist on following their Intentions, the result would be something non-reusable that might be eventually needed to Product B. It might actually be needed right now, but their focused mind was blocked from seeing it.
On the contrary, customers of both Products A and B have asked for the option to pay with PayPal. As his mind is focused on Changing both together, he has the Intention to make a Change for both their designs. That Intention would Cause our Engineer to make a Change to the intersection, where it really is. Different Intentions lead to different outcomes.
Some would say people aren’t suffering from tunnel vision, that it is just people being unprofessional. They just don’t pay attention to details, lack responsibility or ownership. Let’s think of our most responsible employee who knows every detail by heart and he is also a prophet who can anticipate every consequence. Neglecting the above is not only arguing against a Nobel Prize Winner, but it is making our favorite employee’s life harder.
Let’s not forget that we are being unrealistic here. Products and applications are complicated and grow to be more complicated. It is an incorrect and an impossible expectation of our employees to predict and know every little scenario. The kind that builds up to eventually them leaving the company. As it is our responsibility to manage that, it would be irresponsible to presume their replacements would be able to do the same. It would also be irresponsible to do nothing about it.
Paths
If we wish to prevent our Engineer and PM from making a Change with unintended consequences, we better make sure something will stop them from doing so. Modules A and B are already aligned with the Intentions to Change each product independently. Let’s reuse the very same alignment with Changing A&B together. Let’s make Subscriptions into its own Product and Module C.
Consequently, supposedly this action also creates a new tunnel in the Change Stream, one to match incoming Changes to Product C. But we have done nothing to the Change Stream. This tunnel has always been there, letting Changes to A&B together go through it. It was only uncovered by us when we declared it to be a Product.
A correct and beneficial integration between Module A and C would create a clear line of separation between the two, a sign for our Engineer’s focused mind to pause and refocus. Even when he traces the bug to behind that line, he’ll know that any Change made to Product C would not be aligned with his Intentions. He’ll be able to notice his Change has gone in the wrong Direction (A -> C).
He should stop, and make the Change in the right Direction (C -> A & B). The very same Direction he uses when he wishes to make a Change to Product C alone. These Directions of Change are our way to overcome tunnel visions, to prevent Instabilities and inefficiencies.
If it sounds familiar, it’s because this is somewhat the result of Domain Driven Design. It is a design separated according to the criteria of independent v.s. related business domains. We came to similar results because different business domains do have different Intentions behind them.
We may have noticed that Intentions do not necessarily come from our Engineers. They are something carried from our PMs, Causing our engineers to Change. In the next chapter, we’re going to continue tracing these Intentions, we’ll go further up the Change Stream all the way to its Source.