Have you ever felt like you’re missing something when doing some system component desing. When we read books and watch conferences everything is peachy, but somehow not in your case. You start doubting yourself it was so simple and now? Why the things I make seem to be somewhat skewed.
For a long time I shared that feeling. Trust me I understand you. It turned out that as always there was an error to be corrected. It was all about names..
Here are the most fatal mistakes I’ve made during all my years. I share them with you so you won’t have to! Please learn from my mistakes!
1. Naming too soon
The first and most often made mistake. We start the design sessions from naming components. WE KNOW what it is before we even begin. We slam the first thing that comes to our mind almost shouting: I won!
Shouldn’t we name it? After all, we need to define something. So yes, we need to give it a name, and no we shouldn’t do it. Giving some components a MEANINGFUL name from the start is not a good idea. This defines its scope and responsibilities IMPLICITLY. That means in everyone’s mind, without ever speaking them out loud. This is dangerous. Remember we are in this session to BUILD COMMON UNDERSTANDING, not to throw nouns and draw arrows.
This seemingly innocent act will have serious repercussions later on when you continue on your fatal path with further mistakes.
2. Allow name to influence the design
You have your name, you know that this part of the system is named: Billing. What’s the problem with that? The problem is that all questions have been answered. And I mean all of them.
And that’s it. It cannot be touched, it cannot be questioned, it cannot be extended, it cannot be removed. It’s NAMED and it stays where it is and does what everybody ASSUMES it does, no matter whether it should or not.
There are lots and lots of implicit assumptions that go with a name. Your design session will suffer. You will create closed sub-optimal solutions. You’ll look at components and follow their names, and their assumptions and limits. Billing is Billing it cannot hold Customer Profile. Yes! But maybe in your case, you shouldn’t have Billing and Customer Profile separate? Maybe your design needs Customer Financial Profile? Do you see where I’m getting? You create your own limits!
Do not let names influence your design.
3. Not changing bad names
There is a time when you can fix all of the previous problems. You can step down from the wrong path and change the name! You can choose one that will better reflect what this component ACTUALLY DOES and should do. Not what we wish it would do, or what everybody ASSUMES it does.
A good practice is to question names and try to find even unrelated ones. Throw some contradictions, it will open your mind, and take down the fences. What’s most important, don’t be afraid to change the name, just don’t…
4. Changing name too often
Of course, if you start changing component names with each iteration of responsibility refinement, it will also backfire. You do not only stop helping but you’re actively harming the cognitive capacities of everyone involved.
What makes people think they understand? It means only that they can build (imagine) a cohesive logical narrative of one thing leading to the next in their heads. Let me repeat that: people feel they understand if they can build a cohesive narrative in their heads, it does not have much to do with actual understanding.
So if you change names too often, then people will stop following, and reconstructing the narrative. They will default to the last known state and you stop moving forward with your design. Changing names too often creates confusion!
5. Leaving bad name
If you know that this part of the solution has a bad MEANINGFUL name, don’t you dare leave the design session with this name untouched! It will sink in. What’s even worse It will create assumptions. All of them will be IMPLICIT and UNVERIFIED. Reversing it will cost a great deal. The damage to understanding and vision of the solution may not be reversible, and it will drag endlessly.
6. Not using surrogate names
So what can we do to create our cohesive narratives and not using names? We cannot create a sentence without a subject. We need sentences to describe and do a walkthrough of our solution, to build the vision.
Use MEANINGLESS surrogate names. What does that mean?
Instead of naming some component: Billing, just name it Omega, or Sigma Pi or any other creative meaningless name. It ACTIVELY PREVENTS your brain from creating harmful assumptions about this component.
It gives you space and time needed to do actual analysis and desing. You will be able do draw meaningful and real boundaries and responsibilities of system components. Then and ONLY THEN you are allowed to open your domain vocabulary and pick the right names.
7. Overusing surrogate names
Of course, we can go too far. If there are more than 3 components with meaningless names then creating cohesive vision and narrative becomes nearly impossible. You will increase the cognitive load beyond the productivity threshold, actively harming your performance and outcome.
What to do If we have more than 3 components with surrogate names? Subscribe to my mailing list to find out!
Summary
When you’re in a design session, working on component responsibilities and boundaries use MEANINGLESS SURROGATE NAMES. Only when you strip all unnecessary responsibilities form component then is the right time to go to your domain vocabulary and pick correct names. As always use our Cross-Domain Knowledge Transfer to get most of this article!