Production Code, Maintainability, and He Who Follows After

time to read 2 min | 342 words

Yesterday I wrote about a piece of code that I wrote which I hoped would never reach production. Oren Ellenbogen has posted a long comment about it in his blog. The gist of the comment, you should think about maintainability over hackish elegance.

I tend to amuse myself writing some code that tests the limits of what the compiler can understand , and usually goes beyond what most developers (me included, most often) can grok. Those pieces of code do not generally get into production code. Usually my production code is much more… subdue than what I would post on the blog. I don’t think that posting about yet another login page implementation is interesting enough to write about.

I thought that I made it clear that I didn’t like the solution that we ended up with. It was fragile, hard to explain, hard to understand, and I have no idea whatsoever why it works. It is something that is cool for a hack, but it is not something that I would want to maintain or work with for any period of time.

In this case, though, I provide technical expertise only, and I don’t have control on the decisions. Luckily, technical problems has assisted me in taking the level of abstractions a notch or two.

I can very easily create a piece of short, concise code that will look nice, comply with all the little rules that programmers have, will work and yet put the fear of God in any developer that will try to maintain it. I even do it sometimes, but not in production or non throw-away code.

I have to maintain a legacy project, one that is ten years in production, mission critical and completely incomprehensible. I have a very healthy respect for the guys that will come after me. This mean that I will be smart, but I will not be wise ass.

That guy that will have to maintain my code one day may very well be me.