Barriers are created all the time on software projects (by organization layout, role definition, project management, or indiscriminately) that keep developer knowledge separate. Sometimes these barriers are referred to as silos. We can create better teams and products for our organizations if we can break down these silos -- or if particularly scrappy, blow them up.
This presentation was given to our group of developers at an offsite. I worked with many of these developers on relatively closely related projects. The catalyst for this presentation was my observation that team dynamics on my current project plus at least the previous four had somehow or another encourage some amount of knowledge siloing. This fact has at various times become inconvenient for me personally and by extension my current and previous projects.
Some silos from my past
- I knew something that no one else knew (at least at one point) and was approached about it months later and asked to explain it to a new developer. There was no one left close to the project to help this person come up to speed. If I had imparted this knowledge in closer time proximity to the original construction of the code, the likelihood of a maintenance developer sharing my knowledge would possibly be higher.
I came onto a project that was about 3/4 complete. I was tasked to implement various new features that spanned the application. For specific portions of the app, there were often very specific, singular persons that I sought out in order to get a feel for the code more quickly. If these people were unavailable or over-burdened, as was often the case, I was left to do the detective work that necessarily was more inefficient and took more time. Perhaps if more people were educated on various portions of the app, more fellow developers would have sufficient knowledge to give assistance.A developer on a project that I recently rolled off of was on an extended vacation. He had worked on a complicated portion of the app that I had been less-than-eager to touch (and possible trigger massive explosions). While he was gone, there was an issue and I was asked to consult on the solution. My inexperience with this portion of the software was weighed with what turned out to be a low level of urgency, and we decided to wait until the original developer returned to face this issue. Perhaps if I had dug into this code earlier in the presence of the original developer, the issue would have been dispatched more quickly when it arose amongst limited resources.I recently completed the point-0 version release of a software project. This project was on an aggressive schedule that the developers responded to by each scrambling to get features of the software complete, often in isolation from other developers. The result ended up to be ok. The product shipped complete, but the innards of the software were often inconsistent in their style, how they flowed and handled problems, and the DRY principle was broken several times through recreated business logic. Perhaps if the developers had spent more time in communication about their solutions to separate features, a more consistent, stable, safe, non-repetitive product would have been created.I was recently on a project where, and I've done this several times myself, one person had (fantastically) tackled numerous hard portions of the development by himself. These pieces were so complicated, in fact, that they were bug-prone. On several occasions, when there were problems with these modules, this one developer was always called upon, sometimes late at night or on the weekend, to resolve them. This led to a burn(-ing, then -nt out) developer. Perhaps if more fellow developers had been pulled in to assist with those modules, more people would have been able to share the load troubleshooting more easily.Well, these are some of my experiences. I feel that knowledge siloing probably negatively affected each of these scenarios in some degree. I feel that each challenge was, in the end, overcome. I think that speaks to the caliber of individual developers that I've worked with being able to adapt to their ever-changing, imperfect environments that they are asked to work in. At the same time, I feel that we can often make situations a little easier on ourselves if we're introspective enough to ask the right questions to help guide ourselves out of knowledge silos. Here are some potentials:
How to choose your pair
- What don't I know about?
- What's high risk?
- What's highest priority?
- What's the hardest/easiest? Why?
- What has the least/most bugs? Why?
- What's behind/ahead of schedule? Why?
Once we ask those questions, let's use the answers to help us:
Silos in our future
- Consider how you can open knowledge silos you've been privy to
- Consider what silos you don't but should probably know something about
- Consider how you'll influence the organization to form fewer silos
