Bring rogue programmers in from the cold.

One interesting resource for programmers is "The Daily WTF". It is a great place to read about things that should *not* be happening in your organization: antipatterns for code and business processes (mostly code).

A recent "The Daily WTF" discusses the plight of a company where a “rogue” programmer built an inefficient spreadsheet for a supervisor, only to find it was too popular and those inefficiencies brought down the database by overloading it with connections. Operating outside of IT, the understanding of enterprise requirements was not there. On the other hand, many have argued that rogue programmers exist because of unresponsive IT departments, and they provide a valuable service.

The irony is that “rogue” programmers can easily be replaced in most companies by a small number of junior programmers that report to IT itself. Once a skunk works application is conceived and built, IT can use it as a prototype for a real solution to the problem.

In the article, the rogue programmers “application” is a nightmare for IT: because they didn't review it and bring it up to standards. On the other hand, any IT department that can't take a working (even if for a single user) application written by an outsider and convert it into a real, audited application in short order needs to be sacked. The specification is a functional prototype made using tools that limit expressiveness and probably with a skill set that is simplistic at best. If IT can’t trump that quickly and simply, it is time to reconsider your IT department.

Our solution to skunk works projects: we encourage them, but we insist that once they are functional as prototypes that IT rework them to fit into the infrastructure. We maintain several real time replicas of the databases; skunk works projects operate off those to avoid disruption of production.

It turns out your users probably know their requirements better that the IT gurus... and can implement a solution or partial solution. On the other hand, only IT can assure integration problems won't ensure. Use each for their strengths and your library of applications will grow with the combination of user knowledge *and* IT robustness. It is ironic that Agile Methods are all the rage; yet realizing that the initial prototype phase can be very effective in the hands of the central stakeholder seems verboten.