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?
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.