Policies for sharing source code between groups are much more effective when they are enforced using automation. Automation is important for reducing dependencies on the manual resources required to make source code sharing effective, as well as to make sure that set policies are followed every day, despite human laziness.
Each development group can leverage automation to document, protect, enhance, and secure the source code for each module.
The key obstacles in adopting automated processes are deployment resources and objections to policy enforcement from individual developers.
Automated tools will take some time and effort to configure to specific environments. Some code analysis tools are freely available open source, and so is JUnit, the unit-testing framework for Java. Commercial tools are also available to automate common development policy enforcement, but those require a monetary investment. Some developers will resist policy enforcement that conflicts with their preferred programming practices. Naming conventions, possible errors, and unit testing requirements are controversial subjects. Even though automation helps to make a code base shareable between several distributed teams, the process is not entirely trivial.
Supplementing collaborative development with automation may present the solutions to its own problems. The investment of time and money is unavoidable, but the benefits will far outweigh the sacrifice once the system is set up and working. Most automated approaches to enforcing development policy are very customizable. Stubborn development groups who do not want to conform to a company-wide standard are easily appeased if some exceptions can be made for their group. Policy needs to be defined in terms of what is mandatory for the entire organization, and what is required only for individual groups. Developers must verify that their code complies with a policy inherited from the company-wide policy and supplemented with group-specific requirements. An automated process with the right abilities will address most concerns, but careful planning is important to identify which functionality will be required.
Sharing a source code base between development groups requires clearly defined goals. Developers and managers will stumble across plenty of obstacles during the transition to a shared code base, and many people involved will question the desired benefits.
One obvious benefit is that a unified development process results in similarities in product appearance and functionality. One group’s shared experiences may prevent other groups from making the same mistakes.
However, the added complexity of each development group relying on code written by other groups will make this level of sharing difficult. For instance, different groups and cultures tend to favor different programming styles, hindering the tight collaboration and unified development process. Moreover, development work spread out across multiple time zones will decrease the odds of the full code base building successfully. At any given time, someone somewhere will likely be in the middle of changing something. When one component does break, whether functionally or with respect to compilation, then every other group that is attempting to build the full code base, or that depends on that one component, will be negatively impacted.
Nevertheless, overcoming these and other challenges of implementing a process for shared development is well worth it, considering the end result of more uniform applications and source code.
Parasoft’s industry-leading automated software testing tools support the entire software development process, from when the developer writes the first line of code all the way through unit and functional testing, to performance and security testing, leveraging simulated test environments along the way.