Simon Butcher

Serf

Posted
Comments 1

Not so enthralling code

People don't seem to realise that computer programming is an artistic discipline rather than procedural office work. Those outside of the field would probably scoff at that remark, after they've put together a pivot table within excel. Just because you can cook doesn't make you a chef.

Your average manager fails to understand the difference between someone within an artistic job and someone with a procedural job — the difference being that to accomplish their goal one designs and constructs while the other follows list of tasks. Just because you're a mechanic doesn't make you an automotive engineer.

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?


Categories Rambling, Coding

Comments

  1. Wow, that's a lot of questions to cover in one post. As a begining, the good managers not only understand what their staff does, but are responsible for assigning the work in such a way that both manager and "serf" know what's required, by when, and sometimes exactly how it should be done. Good managers are rare, because demand far outstrips supply. All companies need managers. But there aren't that many good ones around. Thus, there is a necessary abundance of poor managers. There is non-trivial skills involved in being able to understand people, motivate them, remember what tasks they are good at, and what they are bad at. To remember how they respond to different stimuli, how self-motivated they are, whether they work better in isolation, or if there are people in the office they cannot stand to work with. Seriously, it's not easy. And when it's done well, it's almost never recognised. So Computer Programming is an art, you say. Well, Michaelangelo, sometimes a ceiling just needs to be painted. Two coats of white, thanks. Hold the Genesis. Not every housewive is going to work in Comme Chez Soi, but their kids still need to eat 3 square meals a day. My point is, of course, that sometimes the job requires a code-monkey to just go in there and code. Nothing fancy. Get the job done. If your job is that sort of job, then a good manager, or a good team leader, should be able to get as many programmers as necessary to do the grunt work in tandem. It shouldn't be like trying to herd cats across a river. If your job is not that sort of job.. if your job really is something akin to creating a work of art, then you may be forced to conclude that the job will have to be changed soon. You can always throw your artistic inclinations into private pursuits. Open source for example. Otherwise you're just Picasso painting the bathroom a new shade of blue.

Commenting has expired for this article.