Designing Development Support Infrastructures (Part 4 of 5): The End of "DLL Hell": Supporting Centralized Corporate Development
A Production Cycle Issue
Suppose Company A begins development on a new internal product. They expect the development cycle to take about 18 months. They ask IT which set of tools they should use to develop the product, and development begins with a standard toolkit that includes Windows NT with Service Pack 4 and Office 97.
During these 18 months, IT is likely to upgrade the production platform for the internal network at least oncemaybe even more often. Everything depends on the upgrade cycle that IT applies to its internal network. These upgrades will certainly include new service pack releases, and maybe even a whole system replacement with something like Windows 2000 or XP.
How does this affect our programmers? They started their project with a standard set of tools that quickly became obsolete. They try to keep up by upgrading their own infrastructure, but whatever their investment in this area, they'll always be behind. Why? Because of the very nature of the development cycle. Before they can deliver their application, they need to perform a battery of tests: unit, functional, integration, acceptance and pre-production. Depending on the size of the program they're preparing, these tests can take several months to complete. Worse, it's often impossible for them to upgrade their infrastructure during these tests because it's impossible to program with an infrastructure that's in constant flux. The result: the delivery of a program that's designed to work on an obsolete infrastructure that can no longer be found in the corporate network. This issue is illustrated in Figure 2.
Figure 2 Development and deployment timelines.