Developer Mistrust

February 7, 2008 § 1 Comment

Some time ago I was in a meeting room of a big company with a large development capacity. Rather luckily I was present to observe the company’s strategy of going forward with software development.

It went something like this:

“So this is the way we want to develop; the new process we’ve been working on. We’ve pulled together our experiences so far, and drawn up the best uniform approach that will deliver software in the most stable fashion.”

A powerpoint presentation begins. Below was a model (as I remember it) of the new process:

Developer Mistrust

It’s essentially a water-fall process. The idea is that after the analysis phase designated architects would present to the business a set of possible technical solutions and the business, weighing up the pros and cons, would make a decision as to how to proceed. Once the problem had been essentially ‘cracked’ by a team of analysts and the odd architect, the development work could be passed over to some developers to do. A merit of this process is that the developers could be located offshore.

It’s easy to sit back and make snide comments claiming that we know better, but it’s interesting to dig a little deeper into what’s actually going on here. A process has been created to minimize the role of the developer; it seems that this was top of the list of paramount concerns. One can imagine that in the past the business had been burnt by failing delivery projects, and so the solution is to reduce the involvement of the culpable developers in the future. I suppose it’s a bit like expensive plumbers. They’re a necessary evil one must endure, and so the less exposure and involvement of these plumbers in your day-to-day life the better.

Somehow the organisation has stopped trusting developers; they want little to do with them.

The problem as I see it is that a vicious cycle has formed. Once developers are deemed to be a failure point, the next time the overall software engineering process is refined the humble developer’s role will be further minimized. This increasingly disadvantages the developer, so that they’re even less likely to the deliver the next time. Hence the process is refined further and so on.

It would be a tough sell to this business that developers ought to be involved more, not less.

§ One Response to Developer Mistrust

  • In addition to a trust issue this kind of decision can also stem from a financial concern – after all you can get overseas “labor” for far cheaper than in the domestic market.

    I go into more detail in my post (http://www.mcdonaldland.info/2007/10/21/outsourcing-and-the-economy/) on the economic side of outsourcing but the two second overview is that with a well planned underlying design development work is nothing more than assembly (no pun intended). We see the same trend in factories – as things began moving towards more automated processes, such as assembly lines, the skills of the individual worker became standardized and mattered less to the company than the integrity of the design of the production system (a.k.a. architecture).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

What’s this?

You are currently reading Developer Mistrust at Pithering About.

meta