Smalltalk Debugging: You’re not done when all you do is fix it

Posted by steve | Smalltalk | Saturday 4 April 2009 9:34 am

Here’s a scenario you may recognize. The product your team has been diligently making progress on has a few discovered bugs. A developer agrees to fix one of these bugs. The classic technique that Smalltalk developers often adopt is to setup an environment reproducing the bug, set a breakpoint someplace useful, and run the code. Sure enough, when the breakpoint is hit the developer “walks into” the bug by single-stepping and inspecting intermediate results along the way. The flaw in the code’s logic becomes evident and the program is modified, often right there while inside the debugger. The fixed code is then published into the product’s source repository. Good investigative work, with a quick fix. Move on.

However, if all you do is fix the immediate bug you really haven’t done the whole job. Here are some ideas to consider.

1. I’m an advocate of Test Driven Development. If you’re not doing that then at least have a rich suite of unit tests using SUnit to qualify the code in your product. The responsibility you have as a developer following a unit-test covenant is that you need to create a new unit test demonstrating the code was broken before you fixed it. That means you back your fix out, putting the code back into its broken state. Then you write a new unit test case that exposes the defect. Finally, put your code fix back in and let the new unit test validate it is now working correctly. Another reason you should create unit tests to clarify the logic your bug fix repaired, is that this is a “defensive maneuver.” When you add unit tests, enriching the test coverage over your code, you also protect yourself from a later code change inadvertently breaking things again. When you find a bug, write a test case that exposes it. Then fix it.

2. Does the bug you found exist anywhere else in the code? For example, it’s common behavior for inexperienced developers, when writing, to browse for similar patterns and copy code as the basis for their solution. So you end up with little snippets of code repeated all over the place. In some cases they’re not little snippets. Fortunately, Smalltalk does an excellent job of making it easy for you to find these implementors and senders of methods, and find repeated patterns. Take the time to look for them. Sometimes the method has “neighbors” with similar names. Browse those guys to see if the code is the same there too.

3. Finding the same code pattern in more than one place is also a tip that you have an opportunity. I go by the philosophy that small algorithms should never be repeated in the code. “Copy-Pasted Coding Raids” leads to software debt, increasing your overall software maintenance costs. Find all those common places and refactor to reduce how often the code is repeated.

3. Refactoring is another hallmark of quality software development. When you find common behavior coded in several places in your product, consider that maybe you missed an object in your design. Go back and think about it. There’s probably a new object you can create that exhibits this common behavior and then use that object in all those places.

4. Related to design refactoring, you can look for methods that have way too many arguments. I refer to these as “passing a whole paragraph around.” Refactor that mess and create an object. You’ll probably discover that some of the behavior implemented on the consumer method really belonged in your new object.

5. Sometimes, the bug fix is more than just a simple change to the code. Sometimes you end up writing several lines of code to enhance or correct a flaw in the logic. After you get things working, go back and reflect on the design. For example, if your product uses models and persistence layers to describe and manage your objects and you have a properly separated presentation layer, if the bug was in presentation layer code; maybe the behavior belongs in a model somewhere? In other words, if you added lines of code to the methods that change output on a web page, that’s probably a tip that the behavior is implemented in the wrong place. The presentation layer shouldn’t be making decisions about the content. The presentation layer should be making decisions on how the content is presented. Doesn’t matter whether we’re talking about output to a web page, output to a file, or a report print out. Push that behavior out of there and put it in a model object where it belongs. This has the additional benefit that you can create unit tests to check the content before it gets to the presentation layer. I’ve found that after I extract this behavior and put it in the model where it belongs, an enhanced unit test is needed. Often that new unit test will also show there were bugs in the original implementation.

5. I’d like to make a comment about performance related code changes. In some cases you’re working on a fix that just requires the system to operate more quickly. Classic techniques include caching values, optimizing loops and removing unneeded code. The trick about performance improvement changes is that they almost always trade-off design elegance for performance. That’s okay, but remember that it can also make the code more brittle and easy to break in the future. Before you embark on performance improvements in code, ensure that you have sufficient unit test cases to demonstrate that you haven’t changed the overall behavior. This can mean you have to make some unit tests much richer and add checks for a lot of “fringe” model conditions. And like I used to say when I conducted performance tuning workshops years ago, know when to stop, and measure what’s really happening. Don’t optimize code that isn’t slow.

That’s it. These are lessons I’ve learned from mentors I’ve had the privilege of working with as well as lessons learned from doing things the wrong way myself. These lessons were also learned by seeing other developers get into a mess because these ideas were not considered.


More VEX competition pics

Posted by steve | Education | Saturday 4 April 2009 9:05 am

We’re about 2 hours into the competition event. I took some snap shots with my iPhone.

I’m really too far away for much detail. Hopefully I’ll be able to post some HD video clips later.

NASA has a live webcast you can watch. Just Google for “VEX Omaha competition webcast”.

Just a follow-up note. I’m proud to say that Buffett Magnet Middle School, along with their team alliance partner, placed first place in the competition in the Middle School category. This parent is proud because Nicholas is Team Captain of Buffett’s winning team.

From here the team goes on to compete in the VEX World Championship in Dallas, Texas in May. We’ve already got our rooms booked. When they compete in the World Championship they will be up against High School students. Being as this is the first year for the Buffett team, that should prove to be very exciting.


Create Foundation VEX robotics competition

Posted by steve | Education | Saturday 4 April 2009 6:50 am

Getting into the Omaha Civic Auditorium early this morning. First meet is @ 8:00.

Here’s a photo while things are being setup for the day.