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
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
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
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: