Silos: Why we need them.

Silos are Everywhere.

I’ve worked a few different places. And in every place I’ve heard the buzzword phrase: “We are too siloed.” It isn’t limited to software development–it happens everywhere.

Until recently I thought “silos” were negative. Perhaps you have too. In the context of software development, speaking of them tends to hold an antipathetic sentiment. Contextually we tend to mean: “There are scads of applications being created or maintained, and we don’t all know about all of them.”

You probably have a dozen of these “siloed” projects in mind already.

Silos are everywhere. And (take a deep breath) silos are good. I’ll even say beneficial.

Purpose in Everything.

Step back with me for a moment and consider the purpose of a silo. I may not be a farmer, but there are some basic tasks I know a silo performs (you could apply this to missile silos as well; I’m sticking with agriculture).

It collects homogeneous things.

It protects its contents from outside threats.

It reduces blast radius.

It aids in efficient distribution.

All of these are necessary in the world of technology.

Homogeneity

Homogeneity is critical in the right context. Imagine buying a can of corn and opening it to discover it is something more. Corn, beans, radishes, meat, dirt, grass… you get the idea. I’ll venture a guess you would not be too pleased. You expected corn.

Homogeneity doesn’t mean diversity goes away. Imagine your can of corn is all corn of varying colors. It will make your dish more exciting. Perhaps it would even enhance the flavor! At its core it is still corn and you have the product you expected.

Let’s shift this idea to technology. Specifically application development. Homogeneity surrounds the tools used and the people with the expertise in those tools. You will have people with varying levels of expertise. Some may know the stack well. Others may be learning to use them.

Wherever the people on the team are at, homogeneity means they have a specific and unified goal; to produce a product with an agreed upon set of tools.

Abandoning homogeneity leads to chaos. It would not be efficient to have multiple database technologies or several languages for a single product. Could it be done? Sure. But it adds unnecessary complexity. It would be a can of corn full of beans, radishes, meat, dirt and grass.

Homogeneity is not Exclusivity

At some point we have to say “This is the technology we are going to use. You need to use it if you want to be part of the project.” It isn’t a means of exclusion simply for the sake of keeping people out. Rather, it is a means of laying out requirements for inclusion.

That isn’t to say we shouldn’t consider new ideas. We do well to incorporate the expertise and opinions of others. We do need to make sure the expertise, ideas, and opinions fit into the homogeneity of the endgame.

There are cases where exclusivity is necessary. Typically this would be a security context. Or perhaps a legal context. Even so, I would argue that the silo is not the means of exclusion. The padlock is.

Homogeneity is Beneficial

When your team has goals of the same kind, and you have the same kind of knowledge, it leads to success.

You will spend more time moving forward, and less time arguing.

You will spend more time focused on completing the task together, rather than trying to redefine the solution.

Homogeneity in projects is the difference between picking beans, radishes, meat, dirt, and grass out of the pan, or simply pouring the corn into it.

I realize that is an oversimplification, but it stands to reason nonetheless.

Up next…

In the next post I’ll cover how silos protect their contents from outside threats. This may be more than you expect. It isn’t always the “bad actors” we need to be sheltered from. Sometimes good things in the wrong context cause bad results.

Circling back to agricultural silos, think raccoons and rain (I think I just came up with the next title).

Stay tuned!