We used to call it "throwing it over the wall"—the process of turning over source code for production release. That was in my mainframe days when "throwing it over the wall" was a simple check-in of source code to CA Endeavor. Once we handed over our source code, the rest was handled by production control. The request for approval to promote to the preproduction stage was all that was required. Production control handled the promote, compile-and-link edit, and move-to-production. This simple process of separating production control duties between development teams and production control teams has been a standard process on the mainframe for the last two decades. But developers of today's distributed platforms—Java and Windows developers—just can't seem to figure it out.
But is the distributed platform really that complex, or are we missing something? To answer this, look at large UNIX-based legacy systems. Written in native languages such as C or even assembler, they resemble both the Java/Windows and mainframe worlds. Ask any systems administrator on the UNIX platform. They have the bragging rights to describe a process that clearly separates duties between development and production control. Developers check-in their source code to IBM ClearCase and the system administrator manages one large ClearMake makefile to build the code and move it to production. Different tools, but a similar process to the mainframe. If complex legacy UNIX application teams can do this, then so should Java and Windows application teams.
These legacy processes should not be forgotten. They have much to offer in terms of lessons learned from years of experience delivering critical software solutions to end users. They represent the most sophisticated systems ever designed. They serve as the intelligence in our Apache Helicopters and track our hard-earned cash through complex banking systems. There is nothing simple at all about the applications, or the code that these systems deliver.
