Developer Tools

Vol. 1 No. 6 – September 2003

Developer Tools

Interviews

A Conversation with Wayne Rosing

Google is one of the biggest success stories of the recent Internet age, evolving in five years from just another search engine with a funny name into a household name that is synonymous with searching the Internet. It processes about 200 million search requests daily, serving as both a resource and a challenge to developers today.

A Conversation with Wayne Rosing

Google is one of the biggest success stories of the recent Internet age, evolving in five years from just another search engine with a funny name into a household name that is synonymous with searching the Internet. It processes about 200 million search requests daily, serving as both a resource and a challenge to developers today.

Articles

Another Day, Another Bug

As part of this issue on programmer tools, we at Queue decided to conduct an informal Web poll on the topic of debugging. We asked you to tell us about the tools that you use and how you use them. We also collected stories about those hard-to-track-down bugs that sometimes make us think of taking up another profession.

Another Day Another Bug

We asked our readers which tools they use to squash bugs. Here’s what they said.

As part of this issue on programmer tools, we at Queue decided to conduct an informal Web poll on the topic of debugging. We asked you to tell us about the tools that you use and how you use them. We also collected stories about those hard-to-track-down bugs that sometimes make us think of taking up another profession.

by Queue Readers

Code Spelunking: Exploring Cavernous Code Bases

Try to remember your first day at your first software job. Do you recall what you were asked to do, after the human resources people were done with you? Were you asked to write a piece of fresh code? Probably not. It is far more likely that you were asked to fix a bug, or several, and to try to understand a large, poorly documented collection of source code.

Code Spelunking: Exploring Cavernous Code Bases
GEORGE V. NEVILLE-NEIL, CONSULTANT

Code diving through unfamiliar source bases is something we do far more often than write new code from scratch--make sure you have the right gear for the job.

Try to remember your first day at your first software job. Do you recall what you were asked to do, after the human resources people were done with you? Were you asked to write a piece of fresh code? Probably not. It is far more likely that you were asked to fix a bug, or several, and to try to understand a large, poorly documented collection of source code.

Of course, this doesn't just happen to new graduates; it happens to all of us whenever we start a new job or look at a new piece of code. With experience we all develop a set of techniques for working with large, unfamiliar source bases. This is what I call code spelunking.

by George V. Neville-Neil

Coding Smart: People vs. Tools

Cool tools are seductive. When we think about software productivity, tools naturally come to mind. When we see pretty new tools, we tend to believe that their amazing features will help us get our work done much faster. Because every software engineer uses software productivity tools daily, and all team managers have to decide which tools their members will use, the latest and greatest look appealing.

Coding Smart: People vs.Tools
DONN M. SEELEY, WIND RIVER SYSTEMS

Tools can help developers be more productive, but they’re no replacement for thinking.

Cool tools are seductive. When we think about software productivity, tools naturally come to mind. When we see pretty new tools, we tend to believe that their amazing features will help us get our work done much faster. Because every software engineer uses software productivity tools daily, and all team managers have to decide which tools their members will use, the latest and greatest look appealing.

Software engineers and managers often undervalue the “mental toolkit” we use every day. Your brain can have a far bigger impact on productivity than any tools you can buy or download. Programming languages, compilers, debuggers, integrated development environments (IDEs), static code analyzers, dynamic code analyzers, performance monitors, test frameworks, project management systems, and defect tracking systems: All are fine and useful, but without clear goals and effective work practices you might as well be pounding rocks together.

by Donn M. Seeley

Debugging in an Asynchronous World

Pagers, cellular phones, smart appliances, and Web services - these products and services are almost omnipresent in our world, and are stimulating the creation of a new breed of software: applications that must deal with inputs from a variety of sources, provide real-time responses, deliver strong security - and do all this while providing a positive user experience. In response, a new style of application programming is taking hold, one that is based on multiple threads of control and the asynchronous exchange of data, and results in fundamentally more complex applications.

Debugging in an Asynchronous World
MICHAEL DONAT, SILICON CHALK

Hard-to-track bugs can emerge when you can’t guarantee sequential execution. The right tools and the right techniques can help.

Pagers, cellular phones, smart appliances, and Web services—these products and services are almost omnipresent in our world, and are stimulating the creation of a new breed of software: applications that must deal with inputs from a variety of sources, provide real-time responses, deliver strong security—and do all this while providing a positive user experience. In response, a new style of application programming is taking hold, one that is based on multiple threads of control and the asynchronous exchange of data, and results in fundamentally more complex applications.

But we’ve all dealt with complex and challenging software before—optimizing compilers, spreadsheets, word processing, text rendering, airline reservations, and space-probe image enhancement. What’s different about our modern asynchronous world that makes this particular type of software so difficult to develop? At Silicon Chalk, we refer to that difference as emergent behavior—that is, behavior arising from interactions between components (qualities not observed when working with a component in isolation).

by Michael Donat

No Source Code? No Problem!

Typical software development involves one of two processes: the creation of new software to fit particular requirements or the modification (maintenance) of old software to fix problems or fit new requirements. These transformations happen at the source-code level. But what if the problem is not the maintenance of old software but the need to create a functional duplicate of the original? And what if the source code is no longer available?

No Source Code? No Problem!
PETER PHILLIPS and GEORGE PHILLIPS, DIGITAL ECLIPSE

What if you have to port a program, but all you have is a binary?

Typical software development involves one of two processes: the creation of new software to fit particular requirements or the modification (maintenance) of old software to fix problems or fit new requirements. These transformations happen at the source-code level. But what if the problem is not the maintenance of old software but the need to create a functional duplicate of the original? And what if the source code is no longer available?

This exact problem arises when trying to reproduce the original play of old arcade games on modern devices. The game play is so well known that anything short of the original is unacceptable. Often the source code is available, but it may be incomplete and may not cover all of the patches that were added to later production models. In addition, it is too expensive to provide copies of the original hardware.

by Peter Phillips, George Phillips

Spam, Spam, Spam, Spam, Spam, the FTC, and Spam

The Federal Trade Commission (FTC) held a forum on spam in Washington, D.C., April 30 to May 2. Rather to my surprise, it was a really good, content-full event. The FTC folks had done their homework and had assembled panelists that ran the gamut from ardent anti-spammers all the way to hard-core spammers and everyone in between: lawyers, legitimate marketers, and representatives from vendor groups.

Spam, Spam, Spam, Spam, Spam, The FTC and Spam
ERIC ALLMAN, SENDMAIL

A forum sponsored by the FTC highlights just how bad spam is—and and how it’s only going to get worse without some intervention.

The Federal Trade Commission (FTC) held a forum on spam in Washington, D.C., April 30 to May 2. Rather to my surprise, it was a really good, content-full event. The FTC folks had done their homework and had assembled panelists that ran the gamut from ardent anti-spammers all the way to hard-core spammers and everyone in between: lawyers, legitimate marketers, and representatives from vendor groups.

I assume that no readers need to be convinced that spam is a problem. But even I was surprised at how bad it really is. Some panelists said that the spam doubling rate is down to about eight weeks. I checked my spam, and my doubling rate seems to be a touch slower than that—with a 25- to 30-percent growth rate month-to-month (still pretty horrible). With a situation this dismal, all anti-spam filters can do is roll back the clock a bit: a spam filter that lets only 1.5 percent of spam through will be letting through, in one year, as much spam as you are receiving today (assuming the eight-week doubling; if you believe my 25-percent month-to-month growth, you’ll have to wait somewhat over 18 months to be in the same position).

by Eric Allman

Opinion

User Interface Designers, Slaves of Fashion

The discipline, science, and art of interface design has gone stagnant. The most widely read books on the subject are primarily compendia of how to make the best of received widgets. The status quo is mistaken for necessity. Constrained in this chamber pot, designers wander around giving the users of their products little comfort or fresh air.

User Interface Designers, Slaves of Fashion
Jef Raskin, Consultant

The discipline, science, and art of interface design has gone stagnant. The most widely read books on the subject are primarily compendia of how to make the best of received widgets. The status quo is mistaken for necessity. Constrained in this chamber pot, designers wander around giving the users of their products little comfort or fresh air.

For example: I have before me a collection of books about interface design, written by acknowledged experts in the field, and they contain many good ideas, effective heuristics, and describe traps to avoid what all too many interfaces, especially Web interfaces, fall into. Not one of them, however, points out that the cut-and-paste method of moving text is inherently faulty.

by Jef Raskin