Simon Butcher

Fortunately I work for a company that, for the most part, follows The Programmer's Bill of Rights, but lately some nasty ideas have been brewing in management that are set to threaten my ability to be a good programmer and could turn me into nothing more than a pathetic code monkey.

I still somewhat consider myself a so-called “real programmer” — one that deals with programming with the knowledge of what exactly is going on within the computer, in particular the processor itself; but such knowledge probably isn't so relevant to my current job in ERP development. What is relevant to ERP development, though, is quality programming, since system downtime can cost a company a fortune.

The phrase “too many chefs spoil the broth” is true for any creative work, since it's impossible to successfully have several people work on the same task and achieve a high level of quality. Borrowing a phrase from my days in telecommunications, I would say this is akin to the old dial-up subscriber pool contention ratio — the more people you assign to a single task, the lower the quality of the final product will be. Committees are an excellent example of this!

While the time to complete a task may increase positively as the ratio increases, it will start to plateau eventually access to necessary resources becomes impossible.

The idea that's brewing at the office is that the more developers they can throw at the ERP system, the faster the work will get done, which is possibly true for a very small team of developers. However, they don't realise that the quality of the work will plummet when the group grows to a certain size, which will cost them when the system comes crashing down around them and a thousand employees suddenly become completely unproductive. It's almost a false economy.

Until recently, I was the sole developer for our ERP system, and this group has now grown to two — The welcome addition of a colleague in the US will hopefully take a lot of work off my shoulders. Unfortunately, they want to expand the group enormously and I expect most of our time will be spent bumping into each other as we all struggle to work on the same piece of code.

Inherently, software engineers are the kind of employees that need to work on something on their own. I've never seen two photographers holding a camera to achieve a better photo, and I don't think I will ever see two developers huddled over the same method (or class for that matter), successfully hacking away at it.

This all leads me to a question that perhaps only Scott Adams has already answered repeatedly: Do managers even understand what their staff do on a daily basis?