Organizing development teams

Question

A long time ago, when my company was much smaller, dividing the development work over teams was quite easy:

• the 'application' team developed the applications-specific logic, often requiring a deep insight of specific industry problems)
• the 'generic' team developed the parts that were common/generic for all applications (user interface related stuff, database access, low-level Windows stuff, ...)

Over the years the boundaries between the teams have become fuzzy:

• the 'application' teams often write application-specific functionality with a 'generic' part, so instead of asking the 'generic' team to write that part for them, they write it themselves to speed up the developments; then donate it to the 'generic' team
• the 'generic' team's focus seems to be more 'maintenance oriented'. All of the 'very generic' code has already been written, so no new developments are needed in it, but instead they continuously have to support all the functionality donated by the application teams.

All this seems to indicate that it's not a good idea anymore to have this split in teams. Maybe the 'generic' team should evolve into a 'software quality' team (defining and guarding the rules for writing good quality software), or into a 'software deployment' team (defining how software should be deployed, installed, ...).

How do you split up the work in different teams if you have different applications?

• everybody can write generic code and donates it to a central 'generic' team?
• everybody can write generic code, but nobody 'manages' this generic code (everybody is the owner)
• generic code is written by a 'generic' team only and the applications have to wait until the 'generic' team delivers the generic part (via a library, via a DLL)
• there is no overlap in code between the different applications
• some other way?

Notice that thee advantage of having the mix (allowing everybody to write everywhere in the code) is that:

• code is written in a more flexible way
• it's easier to debug the code since you can easily step into the 'generic' code in the debugger

But the big (and maybe only) disadvantage is that this generic code may become nobody's responsibility if there is no clear team that manages it anymore.

What is your vision?

Answer 1

When you have various "application" teams, you will always end up with replicated functionality - the same type of helper classes, the same problems solved several times over, often in slightly different ways.

The trouble is, nobody really wants to be on the "generic" or "framework" team, and that team has a very hard job both advertising what functionality is available from their code base, and then ensuring that the "application" people actually use it.

You need to designate some lead engineers/developers. The role of these people is to oversee the development of code amongst both the "application" and "generic" teams. They are also responsible for knowing what functionality the "generic" team has available for reuse, and then ensuring that it is actually used (and not just reinvented). Initially making one (or a few) people knowledgeable and responsible in this area is going to spread the knowledge faster than just having a team meeting and saying "hey everybody, here is a new set of APIs, start using them". One of the roles of these lead developers is to administer code reviews, and part of that code review can be to ensure that the appropriate "generic" code has been used, and if not then they can ensure that the offending piece of code is refactored.

Of course the generic team are also going to have to do a good job documenting what they have - if an application developer cannot find what they want amongst the generic code, they will go ahead and write it themself, perpetuating the cycle you currently have.

Answer 2

One of my previous employers had this idea for splitting up development work:

• Project teams that would work on long-term projects, usually 3-6 months long on average, so that it was a given that these would be the big projects that wouldn't be done lightly.

• Continuing engineering team that would work on short-term features that could take up to a couple of weeks, along with bug fixes, and other maintenance work items. The key here is that this group has to be prepared to work in short quick cycles as their turnaround is supposed to be greatly different than the project team.

I wasn't there long enough to see how well this turned out but it is a good idea to my mind. The main point is that there are lots of little bits of work that wouldn't get done otherwise but may be very useful for the overall company so this is a way to get those little bits done in addition to the bigger work items. Anything inbetween the two could be reviewed and either split into little bits for the CE team or wrapped into a project if there are enough similar bits in a common area,e.g. a service pack for a big group of applications would be how to take a few bug fixes and wrap them up for the Project team to do.