Geeks With Blogs
Dev.Hell Harrowing the tech business like it's 1999

Been involved in a discussion about what 'elegant code' means lately. I'll try not to get too C++-specific, but that's what I spend most of my days working in and I'm sure that will show.

Elegant solutions are something that all developers claim to aspire to, but what does that mean, exactly? Code that will impress? Code that uses Design Patterns? Buzzword-compliant code that's built on the latest hot gimmick? While I'm a long way from being a Grumpy Old Programmer, I've been a down-n-dirty C++ for long enough to know better than that.

We all know what isn't elegant. Big fat unstructured functions, global data, copy-and-pasted code, logic that's been encapsulated in the wrong places, if it's been encapsulated at all.  Nested switch statements, gotos, do{ } while(false) constructs, misuse of exceptions. Almost any use of the preprocessor to write actual code.

Many of us make claims that small pieces of code are elegant, but I've seldom heard anybody describe a completed system as elegant. The bigger the project, the less elegant it becomes. "Elegance" becomes a series of flourishes or signature tricks confined to small functions or features, while the rest of the system is hacked and patched together. I put it to you, lads and lassies, that this is an engineering failure. The design of the system AS A WHOLE should  have priority. The big picture should be consistent and definitive; if some of the more granular parts are less than perfect, that's okay.  They can be fixed. More often than not, though, I see crumbling systems bejeweled with tiny intricate classes that do very little besides add to the dead weight.

Let's face it, we software engineers have a definite tendency to overengineer. We all like a challenge, and, when confronted with a mundane task, there's always the temptation to get fancy, if for no other reason than to stay awake. So we write buckets of unnecessary code-- code which is far to intricate to reuse, let alone maintain--and, when, asked to justify its existence, we claim that it was 'elegant solution'.

I'm sorry to tell you. but it's not.

Elegant code is simple, easy to read, and concise. Elegance implies that you will write less code, not more.

The best engineer is the one whose code is the shortest, the clearest, and the easiest to maintain.

If your class library requires a user to implement a suite of specialized templates,  and multiple inheritance across numerous hierarchies, and a thousand functors to hold this all together, and in the end all it does is raise a messagebox? It's not elegant. If I can't work out how a simple for loop runs without having to open a dozen other code modules, the code is too granular.

Make no mistake, I'm all for investing in code infrastructure that can be leveraged to save time and effort in the future--code that will be highly reusable and that will save us from repetitive and dangerous copy-and-paste-search-and-replace coding. Infrastructure that will allow engineers to write less code as they build out the system. I'm a huge advocate of design, but I'm also an advocate of not sweating the small stuff.

Over-engineering usually follows in the decadent phase of a project that was under-engineered to begin with, and it's completely counterproductive. You want to prove you're a real engineer? Next time you want to build something frilly and decorative--you know it when it happens--go instead to the bits of the project you don't like to look at. The old modules that your much-maligned predecessor wrote, in between puffs on the crack pipe. The decaying structures where the real work of the system happens--or should happen. Get in there and work out how to fix it. Find a path that will allow you to fix the fundamentals of the system without hurting the build out of new features. Work out how much time and code it will save and sell it to your management team. I guarantee you'll get more satisfaction from deleting a thousand lines of crap code and replacing them with one than you will from checking in a thousand lines of new code that does bugger all, but does it in a really pretty and buzzword-friendly way.

Be an engineer, not an decorator.

-- JF

Posted on Sunday, October 7, 2007 8:43 PM | Back to top

Comments on this post: Decoration

# re: Engineering vs Decoration
Requesting Gravatar...
great !
Left by Forum on Jul 26, 2008 7:22 AM

Your comment:
 (will show your gravatar)

Copyright © Jason Franks | Powered by: