For several years now I've been involved in a long running consultancy project with a local software development outfit. They are a small outfit and, not meaning to be derogatory in any way, their developers are mainly self-taught from the bedroom hacker school of coding. This team freely admits that they have been lacking in professional software development skills and they brought me in to help them improve their development practices. One of the big issues for this team is that they do not behave as a team. Although some of them work on related aspects of the same system they all behave as a bunch of individuals who each work on their own individual projects. Before I started working with them they weren't even using version control and had no real central code repository.
I had a consultancy session with staff from this team yesterday and they came to me with a problem which lead to much interesting discussion. In the past this team has never engaged in code reuse, partly because they all work in isolation, and mostly because they had no coordination mechanism (repository) through which code could be shared. Since I started working with them the team has moved on in leaps and bounds. They now make use of a version control system and have decided that they could work smarter by reusing common components. Yesterday's discussions were borne out of the need they have identified to create a common set of libraries for the team which contain these common components.
The issue that was exercising the team yesterday was how to best create the library in such a way so that the code in it could be shared between developers and used in different projects. On the rare occasion in the past when they have reused or shared code this has been done through sharing at the source code level, either through adding a project from another Visual Studio solution into the current project or by replicating source code from an existing project into the current project. The team was wondering whether they should continue working in this way, or whether they should reuse code by sharing the built binary versions of their component library. They thought that sharing at the source level would be the most familiar, and perhaps the most readily adopted, form of sharing to their developers whilst sharing of binaries would be something new to them. I pointed out the pros and cons of both approaches.
Sharing at the source code level is fragile when making changes to source code that is part of the build for multiple applications. Changing the shared code to fit one application may introduce breaking changes for another application that depends on it and to avoid this scenario developers must be disciplined enough to maintain and execute multiple test harnesses for the various applications and shared components to ensure that any changes made do not adversely affect all applications that share the code. Sharing at the source level also introduces and implicit coupling between all the applications that share the code on developers on one team could find themselves continually playing catch up to adopt their application to work with the shared code that has been modified by developers on another team. Personally I think sharing at the source level is a bad idea and usually best avoided in favour of sharing at the binary level. The disadvantage of sharing at the binary level is that if, whilst working on an application, a developer identifies a refactoring or some shared code that should really be in the shared library, how do they get that code in to the library? We assume that the developer doesn't have permissions to make changes directly in the library (otherwise we are back to the sharing code scenario) so there must be a team with responsibility for the content of the library and proper change request processes in place to allow library users to request changes. As different applications may also depend on different versions of the library binaries, it is also necessary to put the built binaries under version control.
In the case of the team I have been working with I would advise them to adopt sharing via binaries but they really do not have a team spirit yet and do not have sufficiently mature processes to implement change requests effectively. Being a small team they don't have sufficient resource to allocate a small team to take responsibility for maintaining the library and any other approach they would adopt is likely to perpetuate the code ownership ethos that currently exists. To make the binary sharing work effectively I'd also advsite them to install some sort of centralised build server to manage building of the various application and library components and to enable sharing of binaries. The team is still getting used to version control; the notion of building applications anywhere else than on a developers individual machine is totally alien to them at this point in their evolution.
Whilst it's easy to suggest a technical solution of binary sharing, in this instance it is much more challenging and interesting because of the social factors at work in them team and the relative immaturity of their software development processes. In this instance I'd recommend that the best approach to sharing code is the one that works for the team, the one that the developers are most likely to buy in to and work with. I have another meeting with the team tomorrow where these issues will get aired again. It will be interesting to see which direction the team decides to adopt.
del.ico.us | 
Digg It | 
Technorati | 
StumbleUpon | 
Furl | 
reddit