Last week, we discussed one apporach to towards integrating code from other development groups: producing pre-packaged bundles of compiled code for each module. This week, let's look at another approach: share only the raw source code.
Each group can access all of the raw source code and compile the entire code base from scratch. Typically, the source code is shadowed from a source control system whenever it is needed, and all developers use a similar procedure to build the entire code base. Pre-compiled bundles of code are used only for public releases, and all development is done against the latest versions of source code to be committed into the source control system.
Sharing raw source code will overcome several of the drawbacks to sharing pre-compiled bundles of code:
With source-level access, you gain visibility into how shared functionality is implemented.
In-code comments become accessible without needing to be published to an HTTP server.
By compiling all shared source at once, you gain the ability to make local changes in the shared code.
Experimentation—one of the best ways to understand algorithms written by others—will usually provide answers much sooner than e-mail queries to groups in other time zones who can provide, at best, a one-day turn around if they understand the question correctly the first time.
Time-critical changes to shared code can be made by one group and later reviewed by the other group which owns the shared code, as long as source control permissions allow multiple groups to modify the same set of source code.
Integration problems arising from structural changes to shared code will be detected at compile time, rather than later at run-time when some modules were already compiled.
The end result of sharing raw source code between all groups is that software development gains more flexibility to respond quickly to change requests and more understanding of the entire code base.
However, there are a new set of issues to tackle when attempting to share raw source code.
The initial setup of a unified build process may not be trivial if some groups have been using different build configurations. Source tree structure, compiler versions, and build script targets must be unified in order to build the whole code base at once. To achieve the required unity, groups must reach a compromise on which build procedures will be adopted by the whole organization, and which will be discarded.
Another difficulty is that developers retrieving source code from a repository on another continent will be hindered by slow network traffic.Moreover, the added freedom of modifying shared code from other groups comes with added risk of erroneous modifications by developers who are unfamiliar with a set of code. Incremental changes to the code base may put it in an unstable state or prevent it from even compiling until a set of changes is complete. Shadowing shared source at the wrong time could interrupt a developer’s workflow. A lot of time can also be wasted when developers who prefer different coding styles and naming conventions go back and forth changing a common piece of code. Detection of errors and compliance with standards before committing to source control becomes even more important when development groups in other time zones are sharing the same source code base.
Next week... Sharing our own experiences with these approaches.
To explore additional resources on geographically-distributed development, visit our Geographically-Distributed Development Resource Center. Or, visit Parasoft's Geographically-Distributed Development page.Photo credit: toolmantim