We’ve all heard of silos of knowledge within development teams, right?  Often they are created by lack of sufficient collective code ownership, no cross skilling within the team, no code reviews, no pairing, etc., etc.  Generally, there are also human issues involved as well; people too insecure about their own coding abilities to risk their code being reviewed, a culture of personal-attack-masked-as-code-review and so on.

Generally speaking these silos are in one of two dimensions; vertical (e.g., “Greg does all the user admin stuff”, “Marsha is the go-to person for report generation) or horizontal (e.g., “Only Bobby touches the schema”, “Leave all the CSS magic to Alice”).

However, I think I’ve “discovered” an entirely new way this symptom can manifest itself – in the dimension of time.  Yes, I’m the H. G. Wells of development team dysfunction!

There is a development team I’m aware of (and I’ve heard of other instances of this pattern as well) where the silos go something like this:

  • The First Wave: Get it working.  Crank out functionality, churn through stories.  Deliver, deliver, DELIVER!  Basically spit out Version 0.1 (Alpha) of the code.
  • The Second Wave: Make it nice.  Refactor, remove duplication, increase test coverage, focus on simplicity, layer responsibility appropriately.

(Hopefully, the “pooper scooper” reference and the leading image now make sense)

Note that this is not the officially mandated or acknowledged working structure for the team, it’s how they’ve evolved given the personel and the constraints they’re working under.

And to this point it seems to be working.  So far, the relative capability of The Second Wave to keep up with The First Wave has stopped the level of technical debt drowning the team’s abilities to continue development.

BUT – and there’s always a but…

Even assuming the team continues to production (they’re not there yet) in this mode of working, to what degree have they created a temporal silo of knowledge around the codebase?  Will the First Wave people really be able to return to the post-Second Wave version of something they originated and be able to comprehend it, yet alone maintain it? Surely the very reasons why they didn’t pay sufficient care to the code in the first replace (thus requiring The Second Wave) is going to be a massive mental and motivational barrier to picking up the most recent versions of the refactored code?

I’m curious to know how this evolves?  Is this a sustainable mode of development where the conditions fit?  Or is it a “first release only” approach?

Advertisements