Danny R. Faught

Software professionals are prone to classic nerdy behavior, but a few may actually be suffering from something deeper that interferes with both their work and their personal life. It may feel like they are from an alien culture and speak a different language, even though they're using the same words as everyone else. In this column, Danny R. Faught describes how this problem has affected him and how you can better integrate into the alien culture if you or someone you know is affected.

Performance tuning is often a frustrating process, especially when you remove one bottleneck after another with little performance improvement. Danny Faught and Rex Black describe the reasons why this happens and how to avoid getting into that situation. They also discuss why you can't work on performance without also dealing with reliability and robustness.

When you search through an ordered list, like a dictionary or phone book, you're probably using the bisection technique to find the information you need rather than starting at the beginning of the book and turning the pages one at a time. In the world of testing, bisection can make your testing much more efficient. In this week's column, Danny Faught describes the basic bisection technique and how to modify it in order to better respond to the real world.

People have been automating software development, testing, and deployment processes since the stone age of software. The toolsmith of today shares a lot in common with these ancestral automation efforts. In this week's column, Danny Faught details how toolsmiths can learn by studying the computer subcultures of the past and present that are similar to their own.

We all encounter things at work that impede our progress. Having the skill to effectively deal with the roadblocks makes a big difference in your overall productivity. Will you get a reputation as a whiner or as someone who pushes through obstacles? In this week's column, Danny Faught offers help with two common types of roadblocks and gives suggestions for reducing the chances that any barricade will impact your schedule.

You work hard to find tools that can help you. You learn how to use and configure them. Then you find yourself working in an environment where you can't even use them. Have you encountered this frustrating situation? Danny and Alan have encountered this frustration many times before, and in this week's column, they're here to say you don't have to abandon all hope. If you're creative, you can still find tools to use–even in the most inhospitable environments.

In this week's column, Danny R. Faught discusses some techniques on how to beef up your networking game. He compares successful to not-so-great tactics for meeting people who can help us. He also guides us in the ways of maintaining relationships. His bottom line: the focus should always be on creating meaningful connections. Networking shouldn't just be about meeting people, but about learning how to wisely judge their value as well.

Want the 4-1-1 on freeware but don't know where to start? A virtual cornucopia of programs awaits your discovery. In this week's column, Danny Faught details some of the testware he has researched, and explains why it's important to have freeware in your testing tool bag of tricks.

The objectives of the paper are to: 1) introduce you to an open source stress test tool, the stress_driver, which you can use and modify in your own environment; 2) explain the benefits and limitations of a general-purpose reusable stress test tool; and 3) describe some of the implementation details involved in building a heavy-duty test driver using a scripting language.

In this paper I will discuss the development and use of the Continuous Hours of Operation (CHO) test which was developed for the Convex Division of Hewlett-Packard. My goal is to help readers with the practical aspects of developing a load test which can be used to help gauge and improve the reliability of a software system. I will briefly mention how we were unable to make much use of currently available software reliability frameworks, partially because of their deficiencies, and partially because of our inadequate knowledge of them. I knew enough about the theories to know that we did not have enough data to calculate a Mean Time to Failure metric; however, we were still successful in improving the reliability of our product and using the results of the CHO test as a release criterion.