ThoughtFactory.CreateThought()

The idea of trust within a software development team is an interesting one. Jeff Atwood argues that a lack of trust between management and the development team can lead to “micromanagement zombies” who mindlessly follow anything management tells them without contributing creatively. I believe that the issue is much more complex than this, as demonstrated by the following comment from the post:

OK, what do you do if:

• Your team regularly commits errors to make the editors of Daily WTF blush?
• They’ve been doing it that way their entire career and aren’t very interested in changing?
• They’re above average coders in the SE Asian nation you live in?

At least you can shoot zombies.

What we have here are two totally different approaches to software development: Fast Food and Gourmet.

The Fast Food approach delivers a bland product that is frequently prepared incorrectly, but it does it fast, cheap and using unskilled resources. The Gourmet approach delivers a higher quality product, but may take longer, will certainly cost more and requires a more experienced resource to prepare.

Successful fast food chains invest millions in making meal preparation as idiot proof as possible. Flashing lights and screeching sirens tell their employees are told when to wash their hands, when to flip the burgers and when to change the oil in the fries. They are micro-managed to the hilt simply because management do not trust their employees and expect them to fail if left to their own devices.

In contrast, a gourmet establishment has higher expectations of their staff. At the very least, they expect them to know how to cook as opposed to how to follow a checklist of specific orders. Most restaurants have to trust their staff to be able to perform their jobs to a certain level without specific instructions.

This parallel exists in many industries; for example, a master luthier would be trusted by his or her management more than the employee working the line in a factory that produced cheap, mass production guitars. Each has a place: some people want to spend $10,000 on a quality custom guitar, where as others would prefer to spend $150 on a cheap hunk of plywood that sort of looks like a guitar. To each their own.

The software development industry is no different. As much as some people would hate to admit it, there is a market for horribly written software that is impossible to maintain but was developed for minimum wage. It may be cheaper to produce a quality product using quality resources and best-of-breed practices, but that is irrelevant when the customer simply does not care about, or cannot afford, quality. These are the same customers who consider Access a viable solution, and who would have never been able to afford custom software before the advent of VB6.

To service these clients it may be necessary to use inexperienced or low-skilled workers and use management practices similar to those found in fast food restaurants. If you know that your resources are incapable of developing a product without guidance then all you can do is hope that they follow instructions and review, review, review.

I’m fortunate enough to work in an environment where high quality resources are the norm, but I have also consulted in the small business market and seen first hand just how common Fast Food Development is out there in the “real world”. Regardless of developer idealism, cheap, dodgy software development is the oil that keeps the wheels of business running. As a quality developer you may not want to work in environments such as this, but that is no reason to stick your head in the sand and pretend that they do not exist or are not an important part of the software development landscape.