Oct 13, 2004

The Passion Will Leave You...

Peter Varhol has recently sat in on an interoperability of .NET and Java discussion presented by Mark Driver. In this discussion, Mark has characterized the present Java developers as Type-A developers, that are described as being highly technical, code-centric, and spend some of their personal time learning new technologies and subtle details of the platform. Mark predicts that the majority of Java developers will be Type-B developers in the next several years. He characterizes Type-B developers as developers whose job is software development, where the passion is lacking.

In saying this, Peter focuses on how development tools will change to cater to this new group, however, the question in my mind is whether this means that the passionate Java developers will lose interest in Java or if Java will become so popular that everyone and their mother knows it? I really think that it is the latter case, and that Java has a lot of things going for it.

In this particular blog entry, Peter does not really say a lot about the tools, but he does talk about how IDE's will need to be able to work at abstraction layers instead of only at the code layer. By this, I assume that he means the concepts like Microsoft's Visual Studio 2005 plans, which attempt to tightly integrate modeling with source code. This is one of the only ways that I see his points in being accomplished.

In another article, however, Peter discusses tools a little more. As a continuation of Productivity is Tools, Peter discusses some of the complexities of our world, where developers are no longer just working in a single language, but are not also working with SQL, JavaScript, HTML, XML, XSLT, etc., etc., etc. This complexity will definitely not lessen, however, our tools will definitely need to deal with this via abstractions, exactly like the above IDE problem is all about.

But Peter takes this one step further. The issue now is now with the IDE, but rather with the debugger. Debugger technology has not really changed a lot over the years. There are some very interesting research items that could make debugging easier, but they have yet to have a debugger that is feature-rich enough to seriously consider it. As such, we are still stuck debugging our applications line-by-line.

Peter suggests, however, that instead of using a debugger, we should utilize testing frameworks, such as JUnit; he is obviously not the first one to suggest this. Martin Fowler states in his Refactoring: Improving the Design of Existing Code that “Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead.

By writing, maintaining, and using unit, functional, and system test tools, you can easily narrow in on exactly what the problem is within the application. As Peter describes, the only way to build truly complete, functional, and reliable software is to test it.

This does not remove the need for a debugger, but it does narrow down how many times that you need to use the debugger, not to mention the repeated use of the debugger to pin-point the error. I would not exactly call this a goal in writing test programs though. I see the debugger as another tool in our tool chest; now that you have that screw gun, your hammer is used less, but it is not to say that you should throw your hammer away.

Filed In