Specialisation and interdependence leads to a higher standard of living

The title of this particular post doesn't tie as closely to the content as you might normally expect.  So, no SEO bonus points for me today - tsk tsk, shame on me!

The background to the title is a little memory game which my fourth form Economics teacher used to try to trick our class into committing to memory something which each student expressed as a takeaway from the year.  I tried to come up with a longwinded statement that my classmates might forget when their turn came to repeat back what each previous person had said.  The class was a bit too lenient, so by the time someone missed out half of my statement nobody cared to flag it up as a mistake.

Anyway, with that 23 year old useless information out of the way, let's get on with the interesting stuff.

Working in a large company with separate IT teams becoming dependent on each others' services, there are varying opinions about the who, when and how of implementing new features.

The current proposed approach for one of the services that I am associated with involves allowing each team to have access to the service's source code and apply the changes that are needed for that team.

On the surface this seems to make some sense, as the team making the code changes will have the most knowledge about the needs of the current project.

With the benefit of hindsight, some of the senior developers are coming to the realisation that a dedicated product team with specialist knowledge of the complexity behind the service might be better suited to develop enhancements.  (Actually, we thought this from the start, but anyway....)

In my opinion, the technologies and esoteric configuration details involved for this particular service mean that there is too much overhead involved for it to be efficient for each project team to develop for their own required enhancements.  The follow on overhead is that there has to be some team responsible for maintaining any and all features - so they have to learn all about that anyway.

Without going into too much detail, here is a high level list of the context switches required for my project's team members to work on enhancements to the service that we want to consume from:

• programming language
• specialised JavaScript libraries
• build system
• artifact repository
• continuous integration system
• virtualisation configuration

When I have some free time, I might take a look into what others have been posting for their no projects philosophy, as I expect that may have some crossover.