Developer Controls Process

DeveloperControlsProcess is an AntiPattern. See ManagerControlsProcess.

Problem:

Who makes sure that software is developed correctly?

Forces:

Software is expensive, and the people paying for it want to get what they paid for.
Developers are experts in software, and know the most about the implications of design choices on the software itself.

Bad solution:

Developers should be in charge of all important decisions, both technical and nontechnical.

Example:

Hotshot developer is flavour of the month. He's given the Global Crozinator 2000 project and told the company needs a slam dunk on this one and Go For It!. He hires a couple of buddy contractors and a Star Wars Pinball Machine, and buys a minibar and a pallet of Diet Pepsi. 12 months later he has an elegant object-oriented framework that can be re-used on all future Crozinator projects, and a high score on the pinball machine. We don't need no stinking customers.

I permit myself to disagree with this one. Many developers I know are very thoughtful and know what it takes to make good software come out. There are naive developers who fit the above profile, but there are also naive process designers, and naive committees composed of developers, managers and users. If this is the anti-pattern, what is the successful pattern? --AlistairCockburn

I've been thinking a lot about control in frameworks recently.. the idea that it is tough to merge frameworks when they each assume that they are in charge of the flow of control. I suppose that one solution is to nest areas of control. For people systems this would mean that there is a macro process that developers and managers have to adhere to, along with micro processes which each are able to use independently of the other role. But, I don't think that either role can be "in control" of the whole thing. Because there are separate concerns, there has to be a unifying framework which facilitates the whole process. The PlanningGame in XP seems to be a good unifying framework.

-- MichaelFeathers

Is this a software engineering pattern, or a management pattern? I think it's management. It's not unique to the software engineering profession - there's always a tension to resolve when you have on the one hand professionals who know how to do what they do, and think they know why (and sometimes they do) and managers who know why things need to be done, and think they know how (and sometimes they do).

For instance, in another domain, who should decide prescription policies in a hospital? Administrators (who have to live within a budget) or doctors (who want to get the best treatment for this patient). There's no easy answer.

And there isn't here, too. Alistair, I think you've been lucky. I've met many developers who don't have the success of the overall project foremost. Many software development shops are one of Handy's (damn, forgotten the name: Professional?) cultures, where people are using the current company as a development stage in their career - nothing wrong with that, but it needs to be accompanied by some commitmment to success in business terms, too.

I've met too many developers who want to puff their own resumes and use the latest technology, who don't want to do what's necessary for the downstream users of their output (e.g. future maintainers, testers, documentors, and even users). Too many of them think that they're done when the code works.

I've also met too many managers who are still trying to get a baby a month, who think the way to get higher productivity is to threaten people with the sack, who impose timescales from above, who think that developers don't need training, and ignore professional development needs.

So, both of these can be Patterns or AntiPatterns. It depends on the other forces.

What's the way out of this? I don't know. ExtremeHumility is part of it. An acceptance on all sides that no-one has "the" answers for big projects involving real human beings. A focus on the objectives first and on the means second (this is related to the Xp Manifesto for clients and developers, I think). A willingness to listen to the other side, and to explain your point of view. Active listening skills. Honest reflection on how things have worked. A focus on correcting mistakes, not finding who is to blame.

I just want SuperHumanDevelopers? and SuperHumanManagers?...

-- PaulHudson

CategoryAntiPattern