Rocket Surgery

In a previous job, I had a trainer for a CASE tool who gave me a phrase that has stuck with me for the past 15 years: “A fool with a tool is just a faster fool.” The truth of this is obvious on the surface, of course, but many times we developers don’t see it happening to us as it happens - the onset is too gradual. I am beginning to see an emergent anti-pattern, particularly among my less experienced colleagues, which has cropped up as a result of Eclipse usage - something I call “Squiggly-Driven Development”.

Eclipse developers will recall that the IDE puts red squiggly underbars under compile errors and yellow squigglies under warnings and design errors such as such as unused variables, private methods that are never called, etc. “Squiggly-Driven Development” is what I call the practice of writing sloppy code, and whenever Eclipse puts up a yellow squiggly underbar or red squiggly underbar under a line of code, correcting that line of code using quick-fix, and considering the code good enough when all the squigglies are gone.

Human nature lures us into treating the red squigglies and yellow squigglies with similar finality. When the red squigglies are gone, all compile errors are gone — we know this. When the yellow squigglies are gone, however, all design errors are not necessarily gone, but we are often tempted to think they are. If you equate lack of yellow squigglies with acceptable design, and if you use Eclipse’s quick-fixes and refactorings to remove them without careful review of the results, several mistakes and problems are sure to crop up:

1. You are making the flawed assumption that the only possible problems are the ones that Eclipse’s static code analysis will find. This is the modern day update of the classic joke: “What do you mean ‘test it?’ It compiles, it must be right!”
2. You might not have turned on the right or the best warnings and checks in Eclipse. Thus, serious problems might still exist that you never checked because the check was not turned on.
3. Some quick fixes and refactorings in Eclipse can introduce further problems. For example, the extract method refactoring in Eclipse can create methods in which formal parameters are modified — a widely (if not universally) recognized antipattern.
4. You are (probably) not checking the impact on coupled code. Removing squigglies often has ripple-effects to other classes. How often do you really go look at those classes? Are they covered by unit tests? Do you really press that preview button on the refactor screens?
5. You are shutting off your brain. Trusting your tool to handle tedious and error-prone tasks is one thing. If you are relying on your tool to do all your thinking for you, then one of you is unnecessary.

Don’t take this to mean that you should not address the squigglies. If Eclipse puts up a squiggly for you, you ought to do something about it — particularly a red squiggly, or that code won’t compile! But Eclipse is quite short-sighted. When it puts up a yellow squiggly, it’s simply telling you that it sees is a piece of code that matching a fragment of an abstract syntax tree that someone said was a bad idea. It doesn’t see the big picture that you can, and can’t possibly know whether the problem is with the flagged lines of code, or the class was poorly designed, or that the whole approach to the problem was faulty.

My point is this: You should always make sure that you are the one in control. Do not let the squigglies control you. To that end, here are my suggestions for avoiding Squiggly-Driven Development without turning the squigglies off:

1. Question the assumptions. Squiggly-Driven Development assumes the design is basically right and there are a few coding problems. If a class has gobs and gobs of squigglies, then the underlying design of the class is probably suspect. Rather than band-aiding the class and fixing each squiggly, STOP. Look at the class and examine its design. Is it doing what it ought to be doing? Should that instance method be static instead? Should a different design pattern be brought into play?
2. Write more JUnit tests - or even better, go Test Driven Development. If you insist on having an automated subsystem tell you if your code is right, at least let it be a unit test that checks the contract of your code — a perfect job for JUnit.
3. See if you can remove the code entirely. If the squigglies come up because you are doing maintenance work, I often find that there is loads of dead code in most systems I work with. Rather than clean up the squigglies in a piece of code, check if it’s being used or referenced anywhere first. Better to remove it than clean it up — faster too.
4. Know - and I mean really know - your requirements. I don’t just mean know what your project manager or team lead told you to write. Know how your code fits into the big picture. Know what code will be calling and depending on your code. Know what code you are calling and will break your code if it changes. Know what business problem you’re solving with your code and be aware of the economic impact of your work. Awareness and perspective are the enemies of stupid code.

So, don’t check your brain at the door. Don’t let the squigglies drive your development. You do the design; you craft the solution that best meets the users’ needs. Let Eclipse handle the tedium, and keep the problem solving where it belongs — in human hands.

This entry was posted on Tuesday, June 6th, 2006 at 2:56 pm and is filed under Software development.You can follow any responses to this entry through the RSS 2.0 feed.You can leave a response, or trackback from your own site.