Prosthetic Programmer

Recently, one of our client's department managers decided he needed a new application, something to help departments he provides services for to submit forms to him. He bypassed the Information Systems Department and brought in a contractor to develop the system. He then managed the project, set requirements, designed screens, and, according to the contractor, managed the development on a day-to-day basis. Eighteen months later the system isn't anywhere near completion, it isn't clear what the system is supposed to do, and the contractor has just relocated to a new state.

The problem was the manager didn't want an expert to develop an application for him, he wanted a ProstheticProgrammer so he could develop the software himself.

Is this an AntiPattern others have seen?

-- FabianLeGayBrereton

I've seen a developer and a user get very close with positive results. They later described their relationship as that of a race car driver and his mechanic. The mechanic tinkers with the car a little bit, then the driver takes it out on the track for a few laps. They made a big point of the interpretation that was required given their different skills and experience. The driver can report a flutter on the straight, then the mechanic must translate that into a course of action. Same with software.

What distinguishes these two cases? I suspect it might be the control relationship between the manager and consultant versus the user and developer. The latter two thought of themselves as peers with a common goal.

It also might be the intrinsic flexibility of a well (re)factored Smalltalk application. If the user got a new idea, the developer was equally excited and always happy to pursue it together.

ExtremeProgramming takes this same relationship and enlarges it to groups. Many of the XP practices exist to keep the communication paths open and the program responsive. I expect in reality the modern racing team is much the same. -- WardCunningham

Department-level priorities may be different from corporate-level priorities. Thus, a department doing "low priority" (non-strategic) corporate work often can't get any of its local "high priority" automation tasks done by the corporate IS department. Their projects lose out to others that are "more important" from a corporate perspective.

Thus, you often find department heads bypassing their corporate IS departments, outsourcing tasks or even whole projects to 3rd parties. Department heads often have budget and spending authority, even if they have no authority over centralized systems development.

This can be ProcessPatterns or an AntiPattern, depending on how it's applied. -- JeffGrigg

Is this a ProgrammerStereotype?