If you’ve been working as a professional software developer for some time, you must have come across a “Spec Coder”.

Spec Coders are usually well-educated, have good grades and know every detail about dozens of specs. Frequently, they come with social skills well above the level of the average (nerdy) coder. They are – therefore – a human resource manager’s dream.

Alas, what they can’t do is write decent code, I mean, readable, reusable, efficient, elegant code. Sure, they’ve read “Kernighan & Ritchie” and they might have taken a three-day Java course, but between their excellent domain knowledge and their (basic) knowledge of a programming language is a big gap in every Spec Coder: a total lack of design capabilities due to a total lack of passion for software development.

This lack of passion clearly shows in their “if-this-do-that-else-do-another-thing” style of programming. You won’t find abstractions, base classes, function pointers, recursion. Just a plain translation of boring spec words into code that sucks.

Here’s an example.

Let’s assume our Spec Coder is assigned the task to write some code for a file system and that THE SPEC says:

3.2 File selection behavior
…
After selecting a file, the file’s record marker shall be undefined, except for ‘blue’ files, in which case the record marker shall point to the first file record.
…

Our Spec Coder will immediately turn this into code like this (don’t worry about the use of global variables here – it’s just an example):

So far so good, at least until someday THE SPEC gets extended (obviously by a non-programmer):

3.2 File selection behavior
…
After selecting a file, the file’s record marker shall be undefined, except for ‘blue’ files, in which case the record marker shall point to the first file record.
If the file system is in state ‘raw’, the record marker shall always be undefined.
…

Again, the Spec Coder will directly translate this to code:

How disgusting! Our Spec Coder didn’t take the time to refactor the code logic according to the new requirement. In fact, a typical Spec Coder wouldn’t even think that refactoring this code was a sensible thing to do. Why? Because there wouldn’t be a 1:1 mapping between the code and THE SPEC anymore. Arrrgh!

Any true software developer would have jumped at the chance. A true software developer would have mentally rephrased THE SPEC to read “A file’s record marker is always undefined, except for ‘blue’ files when the system state is not ‘raw'”:

This code is definitely more efficient and readable. If you don’t like the ternary operator, just use an if-else statement (are you a Spec Coder, by any chance?):

Are Spec Coder’s really dangerous? I think so! Because of their attitude, with every change they make, the code gets slightly more complicated – little by little – until it’s such a mess nobody understands anymore. Once the critical mass is reached, even otherwise decent developers tend to implement their changes by adding little “ifs” here and there. But there is another problem with Spec Coder’s: It is usually difficult to get rid of them, because their usually good spec knowledge makes them indispensable for a company.

Weird, isn’t it?