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?
