In large organizations, the shear overhead that is IT creates these barriers. Developer tasks are often slated with plans one to three years long. IT fears ad

In large organizations, the shear overhead that is IT creates these barriers. Developer tasks are often slated with plans one to three years long. IT fears ad-hoc, one-off, slapped together, or anything like it because it becomes a maintenance problem and takes special skills. For example, in our organization, IT prohibits the use of Access to build applications, because they end up being a versioning nightmare with copies all over the place, and no concept of "source code". End users end up building applications in Access because they can, and it will take them two weeks to get a prototype. If they ask IT to do it, they'll need a departmental budget (politics!) and it will take six months to get started (between people who intentionally slow down process in order to look important, and the filled up timeslots of developers). Then, it will be in the standard IT development environment (for us, .NET and MS SQL) which means it is opaque to the customer, and every change they ask must go through IT, and gets bogged down in IT process. So they go with Access. Two years later, that employee has moved on, and IT gets a phone call from the customer "We have this mission-critical application that has a bug and we need you to fix it!" and then the real pain starts.