Large teams with layered application

Question

I work in a fairly large team (~15 developers) which is currently discussing our working methodology. The software we work on is quite feature-rich and expanding rapidly in terms of scope so the number of developers has increased lately and will continue to increase. At the moment the different developers have different focus areas which they happen to be good at. Some focus on user interface, some on business logic and some on backend. But a UI developer may add something to the backend if he feels like doing it.

As the number of developers grow, we can no longer work in the same team (it's kind of hard to try to follow what 20 other people are doing). Multiple teams working in the same code base could get messy if people are changing "other peoples' code".

We are discussing some alternative ways to divide our tasks, and different people argues for different ways:

• Some think that the current way of doing things is good enough. Sure, a guy who focuses on the UI could make changes to the backend business logic and potentially mess things up. But at the same time we trust him not to mess up too much. Reviews of changes could be enough to make sure that the quality stays good.
• Some prefer that a team is assigned to a specific layer. For example, a team (2-3 developers) could be assigned to work only business logic implementation in backend, while another team could be assigned to work on frontend and a third could focus on the persistence stuff. This would encourage people to be experts in their layer. The down side is that if a UI developer needs something in the backend, there's an overhead with planning if the person doing the backend is in another team.
• A third suggested way is to have teams with members knowing all layers. So one team would focus on a specific type of functionality, and then include members knowing about UI, business logic, backend, etc. This would give the benefit that a team won't need to wait for another team to finish to implement a new feature affecting all layers. The downside people see here is that this could lead to more split-focus between the developers, which could lead to lower quality.

I'm not sure what I'm asking here, but if someone has experience, or know any about any good reading material about this subject it would be appreciated.

Answer 1

Regardless of the structure you choose, the quality of the communication within the team is possibly the most critical factor to your success (assuming of course that the developers have good enough skills).

I am currently working in a project team of 20 developers, for a large layered application. I manage 9 and my colleague manages 9, while we jointly manage the project. We have developers who specialize in the same areas you discuss. Some of them also have some experience in the other layers and feel confident in making changes there. We have fluid sub-groups which we assemble for each feature based on the need. We stress communication as a constant part of the process. This includes meetings (minimal), WIKIs and just going to someone's desk. The team members are willing to help each other out and share their knowledge. When change happens to the code it can impact all the layers directly or indirectly and it is important to maintain that communication.

You mentioned "other peoples' code", and while some on this site have pointed out that the company owns the code,not the developer, it can still be unsettling to be the only developer touching a portion of the code for a while when suddenly someone else makes a change without informing you and you have to fix the outcome. If those two developers talk before the updates happen, the developer experienced with the code can at least provide some background and issues can be avoided. Good communication can again save the day.

Answer 2

My preference would be that each small team specialize in one layer, with that layer being their primary area of responsibility, but that they be cross-trained in the other layers and be able to work in those other layers should the need arise.

Hopefully you have well-defined architectural layers and interfaces between those layers so that, however you assign your developers, they can work in a particular layer without negatively impacting the rest of the application.

Answer 3

Third option for me.

Communication is key, and minimising the reliance on another layer team to finish their bit or implement to the agreed interface correctly can greatly inhibit this.

I also prefer my team to be generalists who can easily move into different areas when needed. Got a new feature? A "person" can work on the whole thing instead of waiting for 3 different people layers to all become available.

By all means have 1 DB expert keeping an eye on things there, and 1 UI expert monitoring that side of things, but having flexible multi talented people, working on feature silos rather than horizontal layers, for me, always works better.

Answer 4

Agile generally prefers 3rd approach. I'm sure most resources about agile recommend this. Major reason for not preferring layered approach is that it would be hard for each team to deliver working software each iteration, because work of one team is dependent on work of another. You could try approaching it so teams on "lower" level would work beforehand the ones on "higher" level, but then it would be hard to communicate changes. Especially if only thing customer sees is the UI. What you want to look for is named feature teams, versus layer teams.

To ensure that experience is properly shared across different teams and layers, it is also recommended to often rotate people between team. This will ensure consistency and quality across whole application.

Also, the note about "other's people code", I would recomend looking at CodeOwnership from Martin Fowler.