Artificial problems

Probably the biggest annoyance I encounter regularly as a programmer is over-engineered code.

I generally think of anyone quoting Djikstra’s reference to BASIC causing brain damage to be a bit of an elitist eejit; languages can’t cause brain damage, can they? But then I see the monstrosities that Java programmers come up with…

I wouldn’t mind so much if these things were over-engineered to be ridiculously stable or ridiculously flexible, but that’s never the case; the result is always the opposite. These programmers use a lot of lines of code to accomplish something that, as long as you think about it directly, is a relatively simple problem with a relatively simple solution.

Instead they construct class hierarchies and enum mappings to implement the abstract factory reverse string visiting command pattern, and make sure that in doing so, there are a lot of lines of code that encode various assumptions inflexibly, such that when someone inevitably says “oh that’s cool, but can you make it do this…?” the answer is “well if we’d done it the obvious way…”. I hate fighting assumptions and constraints in code, and I hate it even more when they only exist to solve problems in an unnecessarily difficult implementation.

An example is a menu system. In any language with first class functions, the way you write a simple menu is a list of (label, action) tuples, where action is a function. What you definitely don’t want, but what we have anyway, is a list of enums and somewhere hidden in the depths of your program a big switch case mapping each enum to a class constructor method implementing the IMenuAction interface. It’s just painful. If you want to add an action, you have to inform three different parts of your program that it exists (the enum list, the enum to class map, and the class implementation). It also means that your menu is distinct from the place it’s defined, so if you want to change the exact label depending on some runtime state, you’re out of luck, because the enum blocks passing any kind of state and the label is stored on the IMenuAction object.

I don’t have any particular problem with Java in general (but I haven’t used it for a long time and am in no rush to change that), but it does seem to encourage painful over-engineering.

Please stop solving problems the user doesn’t have.

When I was a lowly student I used to spend a fair bit of time reading various research papers. A common trend was that many would describe something that was conceptually simple, but they would write it in difficult language, hide it under a lot of maths and obscure their meaning to a point that it was very difficult to understand what they were getting at. I always suspected they did it on purpose because they were a bit insecure and suspected that they weren’t really doing anything as intelligent as their qualifications suggested they should be (which is wrong – novel ideas are valuable regardless of complexity), so they tried to make it harder to understand in a misguided attempt to make their work seem more impressive. In reality, it had a less favourable result. I think there might be a parallel here.

Advertisements

I like blogging

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: