So far in this series, we’ve talked a lot about Blockages, code and design decisions that later need to be Changed or removed in order to continue to make progress. A source of inefficiency. We’ve treated them as something that is necessarily evil, something non-beneficial.
We’ve looked at them as an unwelcomed and unintentional outcome. But using them correctly and intentionally, we can leverage Blockages to our own goals. To use them as a Restriction to others, to prevent them from causing future inefficiencies. And that would be beneficial.
Keys to Handcuffs
At Silo (2017), I was also planning the company’s Compute infrastructure. At that time there were three kinds of Compute available in the cloud. Containers, Functions and Servers. The last one comes with an inefficient maintenance overhead compared to the others, something I wanted to prevent from happening.
There was also no actual need in sight for Servers. But on the contrary, there may eventually be a need for it. Just a few months before I had a project requiring Servers at a different company, so it wasn’t based on nothing.
I could have decided to completely disregard Servers. That would have led to unawarely coding a Blockage, to be later removed by me or someone else. Meaning my own hands today would be creating a potential future inefficiency.
I could also have decided to be aware of Servers, and intentionally code a Blockage that would prevent their usage. With intention, it is no longer a Blockage but a Restriction. And with intention, I may be able to design it to be easily removed.
Problem is, once you create or code something, it is unpredictable and out of our control what it will evolve to. The application will grow around the Restriction, and the application will make it into a Blockage one day. Alternatively, by creating a Restriction for one thing, I may unintentionally create a Blockage for another thing.
Awareness or lack of it, is an insufficient approach to a well designed Restriction. A better outcome will come if I’ll be agnostic to it, to choose not to choose Compute and to remain open to that optional future. That’s not a new approach, it is The Open Closed Principle of software engineering’s SOLID principles: “Software entities should be open for extension, but closed for modification”.
So, as long as no one implements an extension for Servers, others would be Restricted from using it. You can’t use something that does not exist yet. I’m both handcuffing everyone, and giving them the keys to freedom. If I code nothing, it can not become a Blockage. There would be nothing to remove.
Restriction by extension is one technique out of many to reduce the odds of Changes to past work, and not prevent future needs. Which is one of the goals of a beneficial Roadmap. As such, Restrictions can be beneficial to Roadmaps.
At Silo, I created something extensible with Terraform, a dedicated tool to manage infrastructures. I implemented the very same extension for Containers and Functions, which were required immediately. That has also secured the future implementation for Servers, whenever it would be needed.
If the concept of Restrictions is beneficial to technical oriented Roadmaps, are there some techniques for more product oriented Roadmaps? I can think of three I know of. Design templates, branding and the practice of Human Factor Engineering, the official name of UX Design.
Engineering Restrictions
Generally speaking, it would be extremely beneficial to Restrict others from causing future inefficiencies. Either by adding one to the code or the design. Specifically, to prevent other engineers from writing inefficient code.
Some would say that this is exactly the intent and purpose of Software Engineering. Practicing it correctly, and applying Restrictions will prevent inefficiencies. Not applying them at all or applying them incorrectly, and instead we add Blockages that cause future inefficiencies. It is a very delicate matter with dire consequences.
A Restriction that can be easily lifted off is problematic. Everyone can just easily remove them and do whatever they want without any consideration to inefficiency or consequences. They are not at fault, they are simply unaware of it. Which is exactly what speeds up the evolution process towards a Monolith and creates more future inefficiencies.
A too tight Restriction would give no option for any other engineer to move a little, which is needed. It could eventually lead another to fail in fulfilling a business goal, or it would just make it take too damn long. If that happens, a Restriction has become a Blockage. Probably the worst one possible, because it was intentionally designed not to be easily removed.
The Middle Way would suggest to give in to the thought we can not prevent all inefficiencies, because it would be non-beneficial to try and do so. It would also be non-beneficial to give up and have no Restrictions whatsoever. There would always be others who would try to workaround these Restrictions. Give in, and allow them to elegantly bypass your Restrictions, and put those around.
Architecture
Practically speaking, there would be multiple Restrictions to apply to an application. And we also live in a world where we have multiple applications. Some would share the same Restrictions, which would need to be applied to each one individually. Some have their own unique Restrictions applied. The integration and communication between them would also be Restricted, which is what we might call the “System Design”. And as we’ve seen, the underlying infrastructures also have their own Restrictions.
Restrictions are not all done at once, probably not all are thought of at once. They are Technical Tasks to be executed one after the other. And they hold the value of preventing future inefficiency, so they are Deliverables. Luckily, we already know of a practice to help us manage and execute those, The Iterative Roadmap and the Details it avoids. It would be a Technical Roadmap where its guiding light would be what we call The Architecture.
Such Technical Roadmaps, or Architecture Roadmaps, are long spanning. Months and years. Executing one iteratively is beneficial, but an overburden if we just want to plan one. Some other tool is needed to get an easier start. We’ll walk through that one in the next chapter.