Designing Development Support Infrastructures (Part 2 of 5): Local Coding Support Infrastructures
Introduction
All development starts on the local machine. With DOS, Windows 3.x, and Windows 9x, developers had the freedom required to perform their work. But there were significant consequences because of these operating systems; these systems offered no security, and developers could install, run, and configure any application directly on their system's kernel. The consequence: constant system destabilization.
The arrival of Windows NT had a significant impact on development freedom. Because of the NTFS filesystem and Windows NT's basic security capabilities, IT could now lock down the system and ensure that only authorized persons were able to install and configure system components. Everythingincluding the registry, files, and folderswas locked down. A new segregation of technical personnel emerged: those with authorization to modify the system and those without. Of course, system developers were not necessarily included in the first category.
It makes sense when you think about it. A locked system is a safe system. If IT controls what happens to systems, they can control the stability of the system. This method isn't without issues, but it does work...for IT. It doesn't work for developers. If they can't install the code they write, they can't test it. If they can't test it, they can't perform their work.