Boring as a system choice
I think of curiosity as a characteristic of smart people. But this trait has its own shadow.
A little while back, I had posted this video in jest, showing how I have sometimes been the cause of problems in systems.
Curious people are always learning new things and of course they want to put their newly acquired skills to the test. ‘We could have finished module X in half the time if we had adopted this new framework!’ is often an argument made to adopt something new.
When this happens, your spidey sense should tingle. At times, it is the right call. Often, this is a bad idea. Why could this be a bad idea?
- From a people perspective, now you have to train engineers on a new tech. Some engineers will love it. Others will hate it.
- It increases tech debt. Every new technology causes churn in the code base, in the deployment, in the maintenance costs. It increases your training burden. Now you have to tell engineers ‘Yeah, we do X using a different framework’ and they need to learn something completely new.
- From a process perspective, you need to think about scale, security, availability, deployment and all the other important parts of a successful software pipeline
- Finally, context switching time for engineers is expensive. Even if you have engineers who are trained for the new framework, it still takes them out of flow and slows them down.
It is easy to fall into the short term trap — it solves the immediate problem. But as a leader, you need to think about long term implications of these decision.
Boring as a system choice
Boring choices can be asset to your system design. A language, a design pattern, a framework that has been deployed a million times before have known advantages and limitations. Tapping into that knowledge sets teams up for success.
Boring systems have the following characteristics:
- Well understood patterns that scale
- Community support
- Focuses your energies on places where new patterns are either required or is a competitive advantage
Of these, community support is an outsized advantage. Software development is a combination of personal experience plus community (e.g. Stack Overflow). This is the 2022 Stack Overflow perspective on most popular technologies:
Working on the most popular languages results in getting better results from your search engine when you run into problems. Odds are that someone has already encountered the same problem. If they have not, the odds are much better than someone can figure out the problem you are facing.
Principle based decisioning
I find it useful to have principles drawn up and agreed to prior to any such decisions being made. A key principle is a focus on simplicity — what is the simplest set of technologies that will allow us to move fast? At what point will adding something new cause us to start slowing down because we are more specialized? What is our Core v Context — when are we going to build something ourselves vs use off the shelf? Once these principles are laid out, we always test decisions against these principles.
More than just technology
Boring is not just about tech choices. How about your UX design choices? You can choose to adopt one of the ones off the shelf (e.g. material design) instead of inventing your own. And you get a lot of assets at no cost. At the end of the day, all we do is in service to customer outcomes. Customers care about quality and the speed at which we can move to support them. Your choice of frameworks and languages need to put this at the center of the decisioning.
When not to be boring
I do not have a fixed guideline for making a decision on ‘leading edge’ tech, other than ensuring that choices are vetted via the Architecture Decision Logging process. The questions I am looking to answer are:
- Will this work for us in the short and the long?
- What is the industry adoption of the tech? Will we be able to get the expertise needed?
- Is there a unique value add that we cannot get other ways ? (e.g. moving to Rust will offer safer system programming)
- Can we reuse existing assets (e.g. CI/CD pipelines) or do we have to start over?
