Breaking Silo Development

Waterfall was my first development life cycle for at least a few months until I realized that agile was the future back them (10 years ago), I have developed using agile methodologies from SCRUM to Kanban and XP, in some instances. Collaboration and rapid development of code thanks to a cross functional team.

Does it sound good? Yes! Then, why some companies are still using something known as Silo-driven development.

Silo development is very simple to setup fall into that rabbit hole, you basically assign a developer per resource or project. This solo developer is in charge to develop/test the project mostly own his/her own. One can have 5 developers and 5 projects and one can assign 1 developer per project, assuming all developer are in the same senior level. Silo development establish something that for some managers or CIOs seen as a very productive and ideal development environment, but the reality is that they/you may have deal with the following impediments (hopefully no in a daily basis).

You may be creating a simple point of failure; one developer knows everything about your system. What happen if that developer leave with 0 days of notice? (I have seen it happened; it gets ugly very very fast). The developer cannot take a day off, otherwise things at work are not getting done. As a bonus, writing documentation because almost nonexistent because the developer become the source of true for the project.

  1. Segregated knowledge. This happens when the project manager/CIO or whomever oversees the development team, believes that one developer is enough for a project. The issue here arises after sometime, this developer will be the only person who knows all about the project. Therefore, a second developer wouldn’t know how to interact with the code the first developer wrote. It’s not only about code style, but also about the thought behind it. Now, if you try to pull extra resources to a project you may found that transferring knowledge will be the very first step for the other developer who doesn’t know anything about the project, taking more time for new resource to start producing. One developer built it, one person to blame. I have witnessed how much stress this put to your solo developer.  One way I have seen it manifest is in longer development time which causes a bottleneck for the developer itself.  You may be creating a simple point of failure; one developer knows everything about your system. What happen if that developer leave with 0 days of notice? (I have seen it happened; it gets ugly very very fast). The developer cannot take a day off, otherwise things at work are not getting done. As a bonus, writing documentation because almost nonexistent because the developer become the source of true for the project.
  2. A quiet place, I don’t mean the movie! This may give you the wrong impression because in an environment where developers are not sharing ideas, nor trying to solve complex together. It doesn’t really mean they are being productive. Therefore, collaboration is missing. Collaboration and the share of ideas makes your team a better prepare team for any eventually (a developer quits – most common one), it makes each developer almost with the same knowledge across projects. A quite place mean your team in not really growing, neither the developer.
  3. Code Quality, a solo developer is in charge to developer an entire project, usually one will notice that the code base is unique to the developer who wrote it. You may think, that’s why we have best practices and standards. But companies that have a silo development, usually don’t follow them. So, if you need to add resources to  solo developer project, the new resource will have his/her own way to write code (hopefully best practices and standards) which will clash in a back and forth about how messy the code was written or the solo developer will have a hard time understanding the new resource code standards. What I’m trying to say is that since each developer has its own project, there is not need to follow standards because you as the solo developer for the project, there is no one else touching it. That sound very wrong but it happens.
  4. Missing Unit Tests, Oh snap! Unit testing are usually missing when doing silo development. One resource per project, means the developer is expected to manually test on his/her machine, which carries some truth. What I have seem is, one developer is assign to the whole project, the developer doesn’t feel it needs unit testing because him/she is the only one touching the code. On this one I’ll leave you with a question, isn’t a good practice to write unit tests?
  5. Developer stop growing, sad but true. I have been is multiple job interviews when I asked the candidate to describe about the latest tech he/she has used, just to find out that the candidate never installed Visual Studio 2017 or that got stuck developing in .Net Framework 4.0. technology is one thing, but I have also found that developers become a bit automatic on their job. The developer tends to try to solve the problem the same way.  I personally found this topic the most harmful for developers. You can get stuck doing the same thing for years and if you do when you try to make a change you will have a cumbersome time to do it. Think about it your developer can have 10 years at your company but not after saying that number think, is the developer bringing new tech new way to solve problem or he/she seats and do as is told.

Silo driven development is at the long run a problem, that you will be facing more often then you think. Specially if you are trying to hire high skill developers and they leave after a few months of realizing that it’s a dead end for them. Although, you may have an exception with developers that have been with you for years or maybe decades. Remember in our current tech environment no developer will stay in your company for more the 5 years unless he/she becomes manager.  Well, you can get way with it if you hired someone straight out of college.

Hope this help you to realize that Silo development may be holding your team back in multiple fronts, making you less efficient.

Spread the word
  • Yum