In the previous chapter, we talked about Intentions. We saw their unwanted effect, a psychological effect called framing that fixates our minds. In our model of the Change Stream, we’ve named this tunnel vision. It results in both PMs and Engineers making incorrect Changes that have the potential to introduce Instabilities. What takes it from a potential to an actual one made, is the application’s design.
We’ve then redesigned our application to better fit the Change Stream, to our people’s Intentions. We have created Directions of Change for them to follow when they make a Change, to be a safeguard for them against unintended consequences.
In this chapter, we’re going to continue tracing these Intentions further up the Change Stream, starting with the Cause.
Cause for Change
Our story from the previous chapter continues, with an application of two Modules mirroring Product A and B and their shared intersection of Subscriptions.
Let’s pause our story exactly when our engineer is about to make a Change with the Intention for it to affect Product A alone. The Engineer from our story did not wake up one morning with an insight “OMG I found a bug!”, although it has happened to me a lot. Hopefully he had a good night’s sleep, not dreaming of electric sheeps, and happily came to work in the morning. Something must have happened between the moment he sat on his chair and the moment he decided to follow an Intention to make a Change. Nothing happens for no reason, nobody does anything for no reason.
We could say that the reason he went to fix the bug is because there was a bug. It is only partially true. Sure, if there was no bug there would be no bug to fix. But that is still not the reason he wishes to apply a make to fix it at this moment.
To get our minds around this, think of the time you went to fix a bug in the code and found it in a line last Changed two months ago. Something must have happened between then and now, something that Caused you to make a Change right here right now. A reason you haven’t even known about it until now.
The very last Event that happened before we went to make a Change was a Bug Ticket created and placed on our board. Every Change is an Event that has a predecessor, an Event called Cause.
As we’ve said in the previous chapter, something sets our Engineer’s Intention to make a Change. An Intention that already exists, and it was in the ticket titled “Bug found in Product A”. As first there is a Cause and only then there is a Change, it concludes that Intentions come from Causes.
[You can further read about Change and Deploy in Born Together: Evolution to a Bundle]
Now, this is a significant conclusion. Let’s summarize our insights so far from the last few chapters.
- The application’s design of grouping into Modules needs to consider Intentions.
- Mismatching Intentions could lead to future Instabilities and Inefficiencies.
- Each Change in the Stream has an Intention.
- Changes with Intentions have frequencies.
- These frequencies are unsteady, as the Change Stream is unsteady.
If Intentions come from Causes, maybe we need to design our application according to Causes. But where do Causes come from?
Source of Change
In our story, it seems like the Source of Cause was the Product Manager. He had made a Change to the product’s design which Caused the Engineer to make a Change. But there was something that Caused the PM to do so. So he wasn’t the Source, but we can already notice some kind of repetitive Cause-Change cycles.
By the last chapter of this series, Force of Change, we’ll know what the Source is. For now, all we need to know is that it exists and to define its relationship to our Engineer and our application. Because our application should not care whether it was the PM or the CEO who Caused it to Change. Our application should be agnostic to it.
Let’s start by recalling that our application not only shouldn’t care where the Cause comes from, it can not care for it. Applications do not have a mind of their own, the very same reason applications can not understand Intentions.
The only one who can is the Engineer. He is the one receiving the Causes from the Source and transforms them to Changes which he then makes to our application. And he is affected by the Intentions while doing so, as everyone suffers from tunnel vision. He may inadvertently misunderstand the Intention, and he may also conclude the Intention is wrong and put a stop to the Change. It is his responsibility to do so, and not his alone and we made it easier for him to do so with designing Directions in our application.
When our Engineer does make the Change, it would be to resolve the Cause. Without it, there would be no value to his work, so his work would be non-beneficial. He would do it better the better he understands the Cause. One way for him to do so is for PMs and engineers to work closer together. He would do it even better if he’d understand the Source.
When our Engineer makes a Change, he wishes to do so with the practice of Software Engineering. The practice that slows down the erosive evolutionary processes caused by Change. He is most afraid of his application becoming a dreadful Monolith. But that happens less due to a single Change, but due to a Stream of Changes.
Due to it, our Engineer would sometimes wish to refactor. Sometimes it would be premature, sometimes it would be too late and after a lot of time wasted. Sometimes in hindsight it would be proven to have been plainly unnecessary. It is the unsteadiness of the Change Stream that led him to do so, because an application’s design needs to continuously match and correlate to the Changes being made to it. Otherwise, Instabilities and Inefficiencies would occur.
To do so, he’d go ahead and inspect the Source with his toolbox. It consists only of the practice of Software Engineering and excellence of coding and design. Unfortunately, that is not enough. The Source is not an application, it is not code. That is unless we live in a simulation.
Historically speaking, according to Martin Fowler, to understand the Source was the work of The Architect. And his design, the one based on the Source and matches it, was called The Architecture. His goal was to coordinate between the application/system and the organization’s business processes and structure. He needs to consider the effect of an organizational restructure on the company’s software architecture, for example going to a flat hierarchy. Or the effect of transitioning from selling to Small-Medium Business to Enterprises. And vice-versa. I’m not entirely sure that definition still holds today.
Starting with the next chapter, we are going to bridge the gap towards this so-called Architecture. We’d do so by completely bypassing the Source and focusing on the Cause. We’d do so using only the practice of Software Engineering. Through this, we’ll be extending the Engineer’s toolbox all the way through to the understanding of the Source itself.