More specifically, I am looking for books and reference materials that can aid me in understanding team and code structures and the interactions thereof. In other words books, blogs or white papers explaining:
Different strategies for structuring teams that share common code between each other but have distinct individual functions?
To summarise my question I would like to know what would be a good source of knowledge if I were to set up teams in an organisation that shared code but each unit still remained autonomous.
I realise that this question is quite vague but it arose as "we need to share code between teams without breaking each others stuff and causing management headaches and reams of red tape"
This might by more of a PM question, in which case it should be migrated to http://pm.stackexchange.com, however, here is my answer...
Sharing software modules - Software modules can be "shared" as code or as binaries...
Personally I prefer sharing binaries, as it leads to less ambiguity on the matter of which version everyone has and it requires editor to open up the same environment (e.g. VS solution) as the author, thus seeing the same unit test and integration test projects and running them after local compiles.
Software modules and teams...
It is best when each software module has more than one author, that way there is no single point of knowledge which among other things, can lead to bottle necks when there is a need for changes.
Modules can be developed in a team or cross team. Infrastructure modules are usually developed either by dedicated infrastructure teams or cross teamed.
It is easier to communicate within the same team, therefore, it is preferable if modules are developed in a single team.
The are a few common divisions to teams:
- Horizontal teams - e.g. Data team, Engine team, UI team
- Vertical teams - team per product/project (or sub project)
- Vertical teams + infrastructure/architecture team(s)
Horizontal teams are a bi-product of matrix management (a known anti-pattern) and lead to teams that may specialize in something, but do not often receive fresh minds (since the teams can be rather static) and the development time is larger this way (more points of both time and API integration).
Vertical teams are used by methodologies such as SCRUM, however, they can lead to redundancy, since different products may have a lot in common.
Infrastructure/architecture teams research points for process optimization and reuse and can provide reusable components, making product development teams' work easier (once the organization gets used to the new process).
As of books - There is no single book or source of knowledge I recommend, on the contrary, I find leaning on a single point of knowledge problematic. Even the most famous books have some strong points and some weaker. The strong points are what make them famous and are often reachable by common sense, just formalized for the first time in that book. Taking everything a book or someone says for granted is not recommended, especially since what is right in one circumstance is not necessarily right in another.
Try to read as much as you can and take the good and relevant parts for each. Do not be too theoretical about your research, check what works and when, especially what works in your circumstances.
Also, learn from others' experience, both inside your organization and others you know and online, ask how similar things have been done and what was good and bad in those solutions.
