The complexity of Code Sharing in an enterprise organization
“All dev teams should start sharing code!”
I’ve heard this phrase several times, and I always wonder “Why?”. It’s the same kind of narrative when we require developers to use a single pipeline tool: We’re just forcing a concept on people, not considering the individual journey of each team. Furthermore, the “Why” is often skipped and instead the focus is on the implementation.
For instance: “Every team must check-in to a monolithic repository”. I’m not saying a mono-repo is a bad thing, but it feels like the hidden motive is control, which could potentially be driven by fear.
Code sharing is important and valuable because:
- We don’t have to reinvent the wheel
- We can learn from each other through knowledge sharing
- We can improve shared code
I think code sharing is more of a behavioral thing which can be cultivated within a team. As the codebase and development skillset of a team matures, the need for code sharing will emerge organically.
I recognize a number of levels within this maturation process that are explained below.
Level 1: Opinionated code for team use only
Most of the time the code is opinionated and often not considered as a pattern and/or reusable building block.
Also, the code repository is not publicly accessible, and the rest of the organization does not know a particular service or product is available from this team.
Level 2: Opinionated code, publicly available
The codebase is opinionated. In the interest of sharing, the code repository is read-only for other teams. The team also promotes its code in conversations with other teams, which is a good thing.
The problem is that the code cannot easily be used in another context.
Also, apart from ad hoc communication with other teams, how can the wider organization become aware of this team’s codebase and the services it provides?
Level 3: Opinionated code, example code available
The codebase is opinionated. However, the team sees value in reusability and codesharing, and provides example code which is un-opinionated and can be reused by other teams, provided they are aware of this team’s codebase.
A side effect is that the example code has no ‘warranty’ whatsoever, and the example code becomes outdated and unusable. This is the moment the team could realize that it might be valuable to start maintaining a shared building block.
Level 4: Eat your own dog food
There is a lot of value in creating, maintaining, and reusing un-opinionated building blocks. Especially other teams can be assured of the quality because the providing team is practicing the “eat your own dog food” principle.
This takes effort and discipline but will pay off. Unfortunately, the wider organization still doesn’t know about this team’s reusable building blocks.
Level 5: Share reusable building blocks with the whole organization
In my opinion, the best way to achieve reusable building blocks (that other teams want to consume) is by sharing and promoting the code actively in the organization.
This can be achieved with:
- Portfolio management. Implement portfolio management that is always up to date with the services, products, and building blocks of each team. An IT4IT tool like ServiceNow can be used for this.
- A Community of Practice. Recognize innovators that want to share and learn, and begin a pragmatic Community of Practice where active communication is stimulated.
- A Center of Excellence. Patterns might emerge from the work floor and within the Community of Practice. This should be recognized by a CoE that is able to adopt, vet, and promote these valuable patterns.
So how to get there?
The most important thing is that every team has its journey. Maturation and emergence of building blocks will happen, as long as we enable and stimulate instead of forcing people into a straight jacket.
Lastly, if ownership of code and cooperation between Architecture, Engineering, and Compliance is stimulated, we become more in control.
