We've got a new project going on, and at the moment developers have been split into two teams, team A and team B. This project has 2 parts to it which require development throughout the development stack. Very simplified sample of our stack shown below:Each part of the project requires development across the entire stack, so I would typically expect a full stack developer approach which is how we have been breaking down our work within team B, designing and working out the interactions between different parts.I've recently learnt however, that team A want to be in charge of certain parts of the stack, and they are proposing a divide between the two teams, where the Data Abstraction Layer (and putting content in the Data layer) is handled by themselves with no development from Team B. The divide would look something akin to this:To me this feels very un-natural. Each team has different distinct objectives and timescales to achieve these on, but Team B will have a dependency on Team A to implement features. The proposed solution is that common interfaces are defined up-front (there is probably a 2 year timescale on the project so they could be numerous). Team A will then develop the required bits to these interfaces early on despite having their own set of goals, while Team B stub out all calls for the immediate short term so they can progress.I have concerns about this approach regarding:Interfaces may change and Team A may not have the bandwidth or timeto accommodate changing requirements. Bugs in Team A's code could prevent Team B progressing, and again they may not be the priority to fix these due to Team A having a different prioritization queue.Lack of knowledge spread across the teams - Team B may not fully understand what goes on under the hood and may make poor design decisions because of this.It has been suggested that many companies in the industry have sub-teams and must be able to handle this. From my understanding, generally teams are either split how I initially expected (Full Stack) or by breaking up the technology stack like below:So I'm interested in knowing what the rest of industry is doing. Are most splits vertical/horizontal? Does a diagonal split make sense? If a diagonal split were to occur do my concerns seem valid and is there anything else Team B should be concerned about? To note I'm probably going to be held responsible for the success or failure of Team B.
Slicing up the Development Stack - diagonally?
architecture;programming practices;development process;team
Your concerns are extremely valid. Especially the first two points about Team A not having the time to add features or fix bugs that impact Team B. I've seen this happen at my own job quite a few times.This might be a good idea if:It is known that Team A will be working on the projects that require new features in the database, while Team B's goal is essentially to do only frontend features. For instance, if Team B is writing your company's new iPhone app, it's likely that they will not be adding new database fields for a while, as they need to port/reimplement all the features of the desktop version.The full stack has become sufficiently complex that no single dev (or dev team) can effectively own the entire thing. By own I mean not just add features and fix bugs, but understand and care about the whole system to the point that they can avoid adding more technical debt to it over time. In this case, the diagonal split is the sensible move if Team A owns a UI/Web API that's either extremely simple or unavoidably tightly-coupled to the DAL/database implementation (perhaps some internal diagnostic tools?), while Team B does all the complicated user-facing frontend stuff.Management understands the risk of Team A becoming a bottleneck, and would be willing to de-diagonalize things if or when this risk turns into a real problem.I can't speak to what is more or less common in the industry, but at least where I work, there is a clear need for all application developers to be full stack. What we do have are infrastructure teams that develop/maintain our in-house database, our web service framework and our UI framework (did I mention my company is huge?), so that all of our hundreds of applications can have full stack devs while the company as a whole can still provide consistent performance and UI to all of our services.Recently our company has been making a brand new UI framework, so there was a period when some of our new apps were quite badly blocked on bugs and missing features in the new framework. This is no longer the case, mostly because some of us were given permission to submit pull requests to the team that owns the framework (not quite de-diagonalization, but you get the idea).