BREAKPOINTS

Test, Debug, Release, Rinse, Repeat ...

Well, it would stink to work in either the PR department or the software development department at Monster.com right about now. The Infostealer.Monstres Trojan that was discovered attacking the job seeker site late last week just keeps sounding worse and worse. Bad enough that the malicious code collected 1.6 million records containing e-mail addresses, phone numbers, addresses and resume details of job seekers, but now the clever boys and girls at Symantec have figured out what the bad guys want to do with that information.

Continue reading "Monstrosity"

Posted by Kevin Carlson at 12:45 PM  Permalink |

Longtime readers of DDJ will no doubt recognize the name Jim Gimpel. Gimpel Software has, after all, been running its "Bug of the Month" ads in DDJ for sixteen years. Each ad presents a concise description of a code gotcha that compilers won't catch. It's all to sell Gimpel's software, of course, but the ads are popular among readers. Jon Erickson chats with Jim about the phenomenon.

Posted by Kevin Carlson at 01:51 PM  Permalink |

Sometimes the key to finding more defects is simply to review more code in the time available. To do this, you've got to keep your reviews light. Formal code review can be very time consuming, which makes peer review an attractive prospect. Jason Cohen of Smart Bear Software makes the case.

Posted by Kevin Carlson at 02:17 PM  Permalink |

Despite the obvious benefits of the various forms of developer testing, it's still not the norm in most software development projects. The reason why, according to Agitar Software's Alberto Savoia, is what he calls "resistance to test infection." Basically, some of us have the testing gene, and others don't. But that doesn't mean we can't improve our utilization of testing methods. According to Alberto, it basically boils down to "some testing is better than no testing." We talked with Alberto recently, and here's the interview.

Posted by Kevin Carlson at 01:08 PM  Permalink |

Change management is one of those tasks in software development that really comes down more to social engineering than software engineering. The core of the task is prioritization—deciding which bugs to fix first, or to fix at all before the next release. But this decision process is fraught with conflicting human perceptions—namely, what constitutes a "critical" bug. Your best bet to make it work harmoniously is to get everyone on the same page. Francisco Torres gives some good advice on doing this in his article "Change Management and the critical+++++ Anomaly."

Posted by Kevin Carlson at 01:12 PM  Permalink |

If you're doing things the Agile way, you know that the release phase of a project is not the time to do your major testing. That should be done throughout the life cycle. But that's not to say there's no testing at all at this point. It's just a different kind of testing. Scott Ambler explains.

Posted by Kevin Carlson at 12:42 PM  Permalink |

Debugging is a huge time investment for most development efforts. To reduce the percentage of overall development time spent in the debugging effort, you want your debug tools to perform. What governs the performance of a debug tool? It's all about memory access. Green Hills Software's Anderson MacKay breaks it all down for you in his article "Debugger Performance Matters: The Importance of Good Metrics."

Posted by Kevin Carlson at 01:34 PM  Permalink |

For the sake of productivity, we love to have tools and technologies that insulate us from the low-level implementation details of our projects. But as Ed Nisley points out in his column, there's really no substitute for understanding the details of your underlying hardware and software platform.

Posted by Kevin Carlson at 05:29 PM  Permalink |

When you need to debug an application that is split across multiple CPU cores, you face some special challenges. For one thing, there's the debugging equivalent of the Heisenberg Uncertainty Principle: The act of observing your app alters its behavior. This only gets worse when you're dealing with multiple cores. Intel's Julien Carreo discusses this and other issues in "Debugging Asymmetric Multi-core Applications: Part 1."

Posted by Kevin Carlson at 12:53 PM  Permalink |

GNU Make, despite its widespread use, is not the easiest language to debug. If you've been trolling through the output of make -d to track down problems in your makefiles, you know the frustration. With the use of a few clever hacks, however, you can reduce this headache dramatically. John Graham-Cumming tells you how in "Debugging Makefiles."

Posted by Kevin Carlson at 12:45 PM  Permalink |