email article printer friendly

Put Debugging to the Test
Although testing as a development methodology needs refinement, using it as a debugging tool is crucial to better productivity
by Peter Varhol

October 14, 2004

A couple of months ago in this space I compared the idea of developer tools to a hammer ("What Makes Developers Productive?" Java Pro, September/October 2004). My point was that the tools by themselves didn't turn a person into a developer, but if you were already a developer, you could direct those tools in such a way as to more readily accomplish your job.

What does it mean for a developer to accomplish his or her job? Certainly producing code qualifies, as does the quality and efficiency of that code. If a developer produced an application (or part of a larger application) on an agreed-upon schedule, and that application didn't have a catastrophic failure when in use, the developer was considered productive. That used to be pretty much what a developer did.

Today, however, there's more to the application development process than that. Developers work on a single component in an application and may be writing HTML, JavaScript, Java, SQL, or even INI files for the application server. Less code is written, but every bit of code seems to count for more.

And when the components of the application come together and something doesn't work, it doesn't matter that each of those individual components seems to be correct. At this point, it may not be easy to determine who was at fault, if anyone, and what must be done to fix it. This stage of the application development process can be repeated any number of times, until the application is done or abandoned.

There's a dirty secret in software development today, and that is that it's hard. This condition occurred gradually over a period of several years, and a lot of veteran developers didn't notice. In the early to mid 1990s, when Windows was becoming the de facto platform for many business applications and client/server computing was entering its heyday, a variety of special-purpose but simple and popular languages offered easy ways to create screens and connect to databases. These languages included Visual Basic, Delphi, and PowerBuilder, and millions of developers got their start with them. Many developers still use these languages.

The Complexity of It All
What has happened since? Certainly some good things. The client/server model was a difficult one to manage, with direct client access from multiple sources into the database. If writing user interfaces for Windows was easy, getting those same forms onto a Mac or Unix X terminal was very difficult, and maintaining multiple clients was a headache no one needed.