Queues

The third Rule of Acquisition clearly states, "Never pay more for an Acquisition than you have to", ST:DS9, The Maquis, Part II.

So, large American, Car companies want to save money while conducting their business. Business is complex, and computers can help keep track of things, etc., so they use them. Over time, the Information Technology department becomes rather large and complicated in and of itself, so they look for ways to save money there, too. All this is natural.

One of the issues with computers is that they themselves are rather complex, and require considerable training to use, program and maintain. Good database administrators, programmers, systems administrators, etc., are highly skilled people and therefore are expensive. In general, companies are drawn to organize these people by skill, putting like people into like groups. For example, there's a systems administration group, or a database administration group. A programmer, attempting to write or maintain some application needs to communicate with such a group to make use of such expertise, but also to get access to relevant systems to make needed changes.

As the organization grows, these groups change from technology enablers, to technology gate keepers. They become responsible for systems security, enforcing corporate policies, and so on. To reduce costs, these groups are reduced in size until each person is fully loaded with work. The result is that when a programmer needs to make changes in a system, their request enters a queue, and weeks go by before any action is taken. When mistakes are made, more weeks go by before corrective action is taken. This can be true even for the most trivial of changes, where the programmer had appropriate expertise to make changes, but did not have authority.

And, an honest analysis shows that the body count isn't reduced. It turns out that both the requesting programmers, and the servicing administrators are required to fill out paperwork, perform extra unneeded steps, and real productivity is minimal. The customer has to wait longer, and everyone ends up with more overhead than actual productive work. Far from ensuring quality, mediocrity is enforced. This is not the fault of the individuals.

This tendency to crowd people together by type has long been recognized in industry. The resulting stovepipes generate communications difficulties and pointless overhead. It is not unusual for the overhead to exceed an average of twenty or thirty times the amount of real work, as measured in hours. Worse, much of the overhead is geared to measure progress. Data from these logs are used by managers to show that the system is becoming more efficient, even as latencies grow ever longer. These statistics are, of course, wrong, not just misleading.

Clearly, it's no fun to work in an environment that is mired in bureaucracy. But how does one fix the system? The key is to point out just how terrible the system has become for the end customer. Further, one needs to point out how the head count has grown while productivity has decreased. The evidence clearly shows that small integrated teams, with all the expertise in a tighter nit group are considerably more effective. One needs systems administration, database administration, developers, business liaisons all in one place. If single individuals have competence in more than one area, they are that much more effective. That suggests that small groups control their hardware, systems software, and applications software. Small groups should develop their own standards for backup, source control, coding style and database naming conventions, application deployment, and so on.

Sure, the larger company should have policies, but the development group should be able to treat these as suggestions. If they decide to deviate from company policy, they should be able to do so without a waiver of any kind. Then, the policies will reflect business needs, rather than reflect blind guesses.

What about external requirements, like SOX? These are business requirements, like any other. Let the development group handle them. If they require reporting, then reports become policy or part of the automation, as makes sense. The key is that things should make sense.