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.
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.
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.
[…] September 23, 2014 · by Nav Marwaha · in Agile, Architecture, Software development · Leave a comment First of all, I’ll get this out there, I HATE the term ‘Technical Debt’ with a passion, it doesn’t help us in the relaying context, and to those in the business who aren’t working with ‘Technical Debt’, hearing the phrase sounds like hearing ‘my job isn’t easy I have so many problems, please make my job easier’. Let’s talk context, let’s use not ambiguous phrases. So this blog post will discuss “improving development efficiency” but not ‘tackling technical debt’. Very few organisations are in a position to say “we have nothing we’d like to improve in our system(s) and/or software delivery teams”. Even when a business has the all the people it needs with all the skills desired skills and mechanisms to make improvements, there are always things that could be better with the system(s) or applications, this could be any thing from the ownership of logic or validation between applications, to how an application is logging errors, to how domain boundaries are split. A growing business, generally, is always trying to improve its offering. People come up with great ideas quicker than they can be coded, tested, deployed and used in a live environment. However, it’s important to take a step back once in a while to reflect on the system to see where we are, look at where we are trying to get to from a business perspective, and really understand what we require from our systems from an architectural view point. Sometimes it’s even worthwhile forgetting where we are and to just try to get an understanding of what we would like our system look like in the ideal world. Doing this at all levels from enterprise level to sub-system level is really important as the system design will otherwise be determined by project requirements. There be dragons down this road of Project Orientated Architecture. I won’t go into why in this blog post (that’s covered off in Organising-teams-for-a-good-architecture-part-1 and Organising-teams-for-a-good-architecture-part-2). […]