Table of contents
What are knowledge silos?
Most engineers have come across a form or another of a silo. They exist in most teams and sometimes we experience them as blockers in our way of carrying out a task. They have the form of invisible walls that block the information you need to access.
In the code, when silos between modules/functions do not exist, we face a big ball of mad where everything seems interconnected. We change one function to alter the registration form and all of a sudden checkout is not working. Information is shared all over the place, without any walls to protect it.
Silos in your team
Have you ever tried accessing a piece of information and couldn't get your hands on it? You looked up the company's docs and asked one or two devs but no one could help. In the end, you find out that no one knows a thing, except the person who is now off on vacation.
The above has happened very often to me, and many times I was the person creating the silos by not sharing information, as I should have. I focused on delivering the new feature on time but I never created a doc to explain what I did and how. After the feature was done, EVERY developer that worked on it after me, had to contact me for any questions. There was not any other way to get any information about it.
This kind of silo bogs down teams and makes developers' lives harder. Interruptions and long calls happen, usually exhausting both counterparts as it is a mentally demanding activity. I (the silo in this case) have to re-remember everything I built some months ago and try to transfer the knowledge without overwhelming the questioner. The questioner on the other side, has to deal with all my babbling instead of reading a nice doc at their own pace.
Silos in teams are people or groups who hold information hidden from the rest, with or without knowing it. They cause bottlenecks and frustration. They make people feel "on the outside" of things and teams a bad place to be.
Silos in the code
Can silos be a good thing? Well, yes. When it comes to code, creating silos can help you write great code! You want your modules to hide information from the rest. By making every module aware of the specific data it needs, you avoid coupling it with a different one.
What does module mean? In this case, it can be anything of a class, function, or namespace. Let's pick a class to create an example. Let's call our class Logger with the responsibility of logging information in files.
All the information on how to do the logging should be hidden inside that class. No other class should know how to do that except the Logger. With that silo in place, the code is easier to maintain, as you have only a single class to modify in case you need to alter how you log something or where.
Isolating knowledge as we did with the Logger, makes everything more organized and reusable. Your code will be easy to understand and change the next time you visit and your system will survive for longer.
Actions
Thinking about information is part of our job as software engineers. It can transform our teams and code. It can be crucial for a project's success as it affects pretty much everything we do.
Next time you write a piece of code ask yourself if you are crossing any boundaries, or handling information on the wrong part of the code. Hide information in your classes and functions!
After finishing a big task, think about documenting it and/or organizing a knowledge-sharing session to show them what you did, how, and why! Share information with your teammates!