 |
|
 |
 |
|
|
 
Tom Ball's BlogBe a Good HusbandPosted by tball on March 21, 2005 at 11:54 AM | Comments (3)A few months ago I was interviewing at another company (they called during a bad week :-) and one interviewer pulled the classic "find the hidden bug in some tricky code" stunt. In the past I have played along with this nonsense, but this time I refused to find the one bug and instead rewrote the whole method in a simpler way. This led to a long argument on why I refactored the code -- it turns out that the engineer wrote this routine for a key part of their product, and was very proud that mere mortals have trouble understanding it. Since I have a different set of engineering values, my interest in our working on the same project waned. Here's why. I believe that programming is a form of writing (see how far you get with just a whiteboard and hand-waving), but unlike literature or poetry, programs are creative works that (for the most part) must be sustained. A program is improved over time, or at least should always be designed and written as if it will be. (I learned this the hard way, when my private test tool, jdb, was shipped with JDK 1.0!) After any writer finishes a work he or she wants to start the next one, but software developers have to manage their time maintaining existing works versus creating new ones. The more users who depend upon a program, the more the demands for both sustaining engineering and new features increase. Both companies and individual developers have to deal with this problem. The way I think we can get away with doing as little sustaining engineering as possible while still meeting our responsibilities to it is to write code that is easy to maintain. Since we want to focus as much time and energy on new projects (the creative part of our jobs), it means that our old one projects should be written clearly so that we don't waste time having to figure out their complexities. BTW, this is the argument for funding unit test writing and refactoring work that non-techical management can appreciate: these efforts reduce the cost of sustaining engineering without sacrificing customer needs. What does this have to do with being a good husband? One definition from The American Heritage Dictionary defines husband as "To manage or use economically: husband one's energy". The term comes from when most of our ancestors were farmers, where a "good husband" was someone who carefully managed their fields and animals to improve the farm, despite having very limited resources to do so. Since development engineers and organizations always seem to have more tasks than the resources to do them, we need to write manageable code which can be sustained economically. We therefore need to be good husbands to our code, regardless of our sex or marital status! Now, if only my wife would buy this argument when she complains that I am "married to my work." Unfortunately, her definition of how I should be a good husband doesn't involve any engineering best practices! Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
