The Sword and the Shovel

The other day, I was discussing some issues with a friend of mine at work, and he parenthetically commented that a particular section of code was "embarrassing." When I asked him why, he simply said, "Have you seen that code?" At that moment, it was rather difficult to announce that I had actually written that code.

At the time, the company was in a crunch period, and this feature needed to be written, and after some deliberation about how to proceed, I started work. I was given a week, but I started to realize some unexpected complications with the interface I was working with, and then some bugs in that code I was interfacing with, and soon, the week turned into two.

The climate at the time, was quite stressful, and the chopping block was well lubricated. I got the code working by sheer will of an arsenal of unit tests, and when I was done, I was not pleased. I needed to refactor, and I refactored the worst pieces first, but it was clear that we hadn't come up with a good architecture to begin with, and I was already behind schedule…

Now, I'm not sitting in this public confession booth with the feeble attempt at justifying myself, but in having this conversation with my friend, I realized a pearl of truth that I had not been wanting to accept because of the ugly oyster surrounding it…

Engineering has some common ground with politics. That is, when we geeks start on this engineering path, we are in an idyllic state, but over the years we realize that sometimes the sword of insight and truth isn't as effective as the shovel of compromise.

I will admit, that I had been thinking that my agile philosophy would somehow save me from the blight of ego inherent in this corporate compromise… and that the battle of Howard Roarke((+Reference to a character in Ayn Rand's novel, Fountainhead. See this essay for an explanation of this reference)) could be actually be won.

I'm not advocating capitulating or mediocrity, but in engineering, one must look at the goals of one's work. And in a corporate environment, it boils down to money, and while a brilliant, well-architected, piece of code is both easier to maintain and has less bugs, the cost may not be worth the price.

One last thought… this discussion illuminates a crucial feature between the open source software and corporate produced software. Open source developers need not make any compromises, and since their code is open for viewing and reviewing, the sword, and the pride of weilding it, often becomes much more important.

My friend, Doug, said:

The cost would be worth the price if the entire team started that way from the beginning. What's become very clear to me is that most developers don't write their code with the top priority being "maintainability/extensibility/etc". Therefore, when we have to maintain/extend/etc that code (which is the largest part of a piece of code's lifetime), we're faced with a lack of unit tests, good design, comments, etc. And it's much harder (and more boring if its not your code), to put that stuff in after the code has been written. Since it's much harder, it never gets done. Also, there are never checks and balances (strong architect/lead and code reviews) in place to enforce such goals.

We could decide to simply let corporate pressure drive us to being sloppy, but I don't think that would be smart. On the other hand, ensure that you've got lots of headache pills in your desk drawer.

Concerning my comments on open source, he said:

This is a good point. Of course, only the open source stuff that gets widely-used will get widely-reviewed. Therefore, be careful relying on obscure open source stuff.

True, however, the thought that someone could start reviewing your code, may make you want to put unit tests, document, and check your input variables. Of course, not always, but at least you have the luxury of releasing when you feel the code is ready.

Tell others about this article: