The Blog From Hell

Yes, there is a problem with writing [tag]well designed code[/tag]. It’s not a technical problem, it’s a human problem. Perhaps it’s more of a [tag]geek[/tag] problem than anything else, but it’s real enough.
What are (some of) the attributes of well designed [tag]code[/tag]  ?

• It is highly reusable
• It employs a common, standard design across the project.
• It follows known algorithmic best-practices.

And why do we do that ?

• It makes code less prone to bugs
• Bugs that do appear are much more easily fixed
• It makes it much easier to extend the functionality of the code later

This is just a short list of the things that make for well designed code, and the major reasons why it is important to follow the rules of good design. Things like avoid global variables, use object oriented code, abstract away from implementation details in a library to the very greatest possible extent (in theory, a simple library change should allow you to do such a thing as switch to another kind of database server with zero impact on your other code).

So what is the problem ? Well it is like this. When you first start a project, and you follow these rules it is a highly creative and enjoyable experience. You are designing every step of the way, figuring out just how to apply the rules to your specific needs. What tables does your database need ? What should be the class structures you use to abstract it ?
But now skip ahead a year. Your project is stable, it’s working well – there are hardly any known critical bugs and your core features are all there. Your customer calls you to ask a new feature. Adding it is so simple, just add a table to hold the requisite new data, create a class to manage it, and then code the feature into your frontend. Much less work than when you did a feature of similiar complexity back in the start of the project. Exactly the purpose for which you took the time to design the code well…. only problem is… well it’s not hard enough. You spend about an hour being creative to work out how the modifications to the interface should look, the process-flow for the new functionality (from a user point of view) and all that is pretty creative. But it’s over in an hour, then you spend a much longer time implementing it. Sure it’s much less than it was at the beginning since all the hard work is already done – but it’s still long, and it’s extremely boring.
There, I said it, it’s boring to extend well written code. It just doesn’t have any real creative impact.
In the project I am using as an example for the post, my library contains about 30 classes for tables as well as all the code needed to handle the database-basics (connecting and issuing queries and such) once-off. So the classes basically consist of get and set methods (which is good practice) – thousands of them. And they are all, literally, almost identical. The typical set method has one line, and between any two, the only difference will be three words – and they will change identically per method (e.g. the name of the identifier being set).
The get methods are no different, except that the occasionally contain a typecast to get from the database-string to the real datatype.

It’s all very good for the project, but rather bad for the job-satisfaction.
All in all, I am not saying don’t write good code because you’ll get bored. Firstly because in a bigger organization you can usually pass most of the drudge on to the juniors (who need the practice) while focusing on the design part (which remains new and creative at all times), and secondly because if you take as long to add a feature to a mature project as you did when the project was new – you’ll end up with absolute time-management havoc and unhappy customers (just ask Microsoft), and worst of all, you’ll spend nearly all your time trying to fix bugs.
In the end, programming remains one of the most satisfying, fun and creative jobs you can have. Unfortunately it is, by it’s very nature, particularly attractive to people who love a challenge – especially as it remains challenging no matter how good you are at it – but sadly, this becomes less true for a certain project, the more mature that project becomes.

This is, ultimately, an unsolvable side-effect. Extreme programming, [tag]agile[/tag], or any other methodology intended to create better software, ipso facto reduces the challenge when working on established code (that is, in a very real sense, their purpose). It is just not something people usually say (probably for fear that newbie programmers will decide that writing good code is for chums).

Despite our frequent jokes, bad code is still ultimately a bad thing. We may say ‘it was hard to write, it should be hard to read’ – but in fact, we all know deep down, that if you do your job well, the real problem is that it actually isn’t that hard to write (for a programmer anyway).

So, with this not-entirely-serious rant complete, I declare the first silentcoder blog post of 2008 officially completed.