Having codebases owned by specific teams results in better productivity, and can result in a better architecture (if done properly). The worst case alternative of this is having the system not divided up but having a number of teams working on any codebase they feel they need to make a change in depending on the project they have been allocated.

Imagine an organisation has 10 development teams, for the moment the team’s composition doesn’t matter. Now imagine these teams could work on any part of the estate they felt they needed to change. They all have projects or defect fixes they need to work on at the same time. It’s unlikely the teams have any control over what other teams do or even how other teams do their work.

Chances are that within each team you have 1 person that everyone else in the team learns from or looks up to for inspiration on how to do things. Each team is focused on the work they are doing, and everyone wants to do a good job, BUT coding isn’t a science, it’s an art. So each team is likely to have its own practices, its own beliefs, its own short-term and long-term goals, and its own ideas on how the overall architecture should look, both at an enterprise level and at an application/service level. The system as a whole is being optimised for each project.

When a development team is working on a part of they system, they start changing it with a style or design pattern they are most comfortable with and believe in the most. As this part of the system ends up being changed by a different development team each time a change is being made, the development teams as a whole end up making it more and more complicated through project optimisation. This point is really key, as even a subtle difference in approach between teams ends up creating a mess over the long-term when you are looking at a large system. This leads to what I call a Project Orientated Architecture. It’s no so bad when there are only a few elements to the system, but as the number of parts increase and the number of teams increases, development becomes like a game of Jenga.

A system which hasn’t been divided up and apportioned to independent teams for ownership is like jenga. It’s all fine when it’s small, but scary when it’s big enough to tower above you.

To compound this, there is evidence to suggest that the ‘Broken Window Theory‘ holds true with software development. Taking Broken Window Theory as a background, you can expect that if a codebase is in a bad state, a developer working on that codebase is less likely to leave their additions in a good state, especially if they don’t have to live with the consequences. If a development team has no ownership of any part of the system, or influence in its direction, the team is effectively incentivised to do only what is easiest for the specific project they are working on. Optimising at this level tends to make further changes harder, the development effort for projects of the same level of complexity tends to increase over time. If on the other hand a team has to live with the decisions they are making, even small changes are thought about with a longer term view.

Simply put, if there is no ownership at development team level, the ‘system’ will likely end up becoming really difficult to manage, maintain, and make changes to.

After years of not having real ownership at team level, many organisations tend to find themselves in a position where the development cost has increased to unacceptable levels. At this stage many try to reverse the increasing cost of development and change with re-platforming projects/programmes of work, or forming some kind of review board to try to put in place better controls, or even in some cases to get an influx of software architects to provide direction on how things should be done. Some of this can help, but as with any project it’s important to understand the root cause of the issue. This isn’t about using the best technology, or about making sure that the organisation has the best coders or even about putting in place guidelines to make sure people are following the decision-making process. This is about something really, REALLY simple. Consistency. That’s it.

If the Books are the code, the teams are the compartments. Books being owned by a compartment means if one book needs to be replaced with a new edition, it doesn’t affect the other compartments or the books in the other compartments.

Allowing development teams to own different parts of the system means that each team can create their own consistent vision of where their part of the system is going. They are able to understand the improvements that need to be made over time and which changes should be made now. Over and above this, it also means that they now have full ownership, including responsibility and accountability. If something goes wrong, everyone knows which team is best placed to fix it. The impact of this last point shouldn’t be underestimated, having ownership in something allows a team to have pride in their work, it provides confidence that improvements made will not be contradicted or superseded by someone else making changes. The key thing here is that it allows a team to have a future state vision that they work toward, and a consistent understanding of how changes should be made to the part of the system they own.