Common Themes
There is a common theme in both of these "over the wall" processes—both hold true to a very clear separation of duties between development and production control. The key to the process is that developers never build the production executables, nor do they control the process or scripts that create the production executables—and they never release the production executables to production. In both of these environments (development and production control), binaries can be traced back to their source code of origin through footprint technology that captures the information at compile time. Developers are responsible for developing and unit testing the source code, then leaving the rest to teams that focus on getting the steps right.
Java and Windows development teams are now being asked to step up to the plate and hit one out to the cheap seats. Auditors and government regulations such as Sarbanes-Oxley are simply expecting from Java and Windows developers the same level of professionalism that has been demonstrated by developers who came before them. In many shops I visit, I hear CTOs and CIOs complaining that they could pass their audits if only they could put some controls around the Java and Windows development teams. They can't understand why, after spending money on versioning and sophisticated software configuration management (SCM) tools, that they still cannot provide a clear audit trail showing what source code was used to create the binaries running in production—and why they cannot restrict Java and Window developers from having access to production servers.
The answer is not too far in the past. CIOs and CTOs simply need to look at their legacy mainframe or UNIX applications to see the answer. Java and Windows developers struggle with letting go of the process of building and releasing their binaries in the same way as mainframe or UNIX developers can. Most importantly, Java and Windows developers have not sorted out a build process that can be repeated regardless of build location. Their build scripts are ad hoc, have static references, are highly redundant, and are anything but repeatable. For this reason, they "hit the wall" instead of going "over the wall."
