Tom Ball's Blog: March 2005 Archive

Posted by tball on March 21, 2005 at 11:54 AM | Permalink | 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!

Linux Users: run JDK 5.0!

Posted by tball on March 14, 2005 at 01:33 PM | Permalink | Comments (5)

I've been running NetBeans for several months on 5.0. Today I built the development version of 4.1 from scratch and then ran it. The IDE was slower and ugly, and I thought "oh no, what have they broken?"

Then I realized what I did ("Doh!"): the build requires that you set your JAVA_HOME to 1.4, and I forgot to reset back to 5.0 before running it. What a difference the new JDK makes! NetBeans is faster, prettier, easier to use. Sometimes you don't realize how good the 5.0 JDK is until you forget to use it.

The Most Powerful Refactoring?

Posted by tball on March 07, 2005 at 02:01 PM | Permalink | Comments (13)

As earlier readers have probably figured, I'm working on automated Java refactoring technology these days. It's becoming a crowded field with some really good tools already out there, but since I'm a normal software engineer I know I can do better. As Alexander Pope stated, "Fools rush in where angels fear to tread," and as my family will attest, I am no angel.

Now that the Jackpot engine is humming along nicely, our marketing folks want it to demonstrate some "powerful" refactorings from Martin Fowler's book, Refactoring: Improving the Design of Existing Code. From a tool perspective, there are certainly some hairy refactorings to consider implementing, such as "Extract Method" or "Replace Inheritance with Delegation", but I do not use those very often, and when I do it's always by hand.

Perhaps I am looking at this problem incorrectly. The above book defines refactoring as "... the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." I want to add to that description: "... or increases its clarity." As a production developer, I rarely get to work solely on my own code; I inherit other engineers' work and pass it on afterwards to still others. A big source of bugs in this environment is source that is hard to understand, code that doesn't clearly describe its functionality and the intentions of its authors. Consequently, much of my refactoring cleanup involves changes that make the code more "obvious" to the next engineer in the chain. Most well-applied refactorings do just that.

So what is my candidate for most powerful refactoring? It's "Rename Class", which isn't even in the book! "Rename Method" is, however, and the author's description of its benefits also apply to classes and variables. I use the beta 4.1 version of NetBeans, and find I'm frequently renaming classes since its refactoring support makes it both easy and fool-proof (being a fool, I need the proofing!). I change class, method and variable names as my understanding of their purpose improves, and a nice side-benefit is that it makes picking them from a code-completion list faster since their names are more obvious.

So, what refactoring has your vote as "most powerful"?

Powered by
Movable Type 3.01D

java.net RSS Feeds