Build the Installation Program Immediately

[Previous] [Next]

Build the Installation Program Immediately

Begin developing the installation program immediately after you start developing your project. The installation program is the first part of your product that your users see. Too many products give a poor first impression , showing that the installation program was left to the last minute. By getting the installation program started as early as possible, you have sufficient time to test and debug it. If the installation program is done early, you can also incorporate it into your smoke test. This way, you're always testing it and your tests will be one step closer to simulating how the users will be running your program.

Earlier in the chapter, I recommended that you should build both release and debug versions of your product. You also need to have an installation program that allows you to install either version. All modern COM software now requires so much stuff in the registry that it's almost impossible to properly use an application without running its installation program. By having a debug build installation program, it becomes trivial for developers to get a debug version on a machine so that they can quickly start debugging a problem. To ensure that no overlap problems between installing debug and release versions occur, you should probably have different registry keys for both your debug and release products.

One extra benefit of having the installation program done as early as possible is that others in your company can start testing your program that much sooner. With the installation program done, the technical support engineers can start using your program and providing you with feedback—early enough in the cycle so that you can actually do something about the problems they find.

[Previous] [Next]

QA Must Test with Debug Builds

If you follow my recommendations in Chapter 3, you'll have some excellent diagnostics in your code base. The problem is that, generally , only the developers benefit from the diagnostics. To better help debug problems, the quality engineers need to be using the debug builds as well. You'll be amazed at how many problems you'll find and fix when the QA folks do their testing with debug builds.

In the initial stages of the product cycle, the quality engineers should be alternating between debug and release builds. As the product progresses, they should gradually start concentrating more on the release builds. Until you reach the alpha release milestone, at which point you have enough of the features implemented to show customers the product, you should have the quality engineers use the debug build two to three days a week. As you approach beta 1, they should drop to two days a week. After beta 2, when all features and major bugs are fixed, they should drop to one day a week. After the release candidate milestone, they should be on the release build exclusively.

[Previous] [Next]

Summary

This chapter covered vital infrastructure requirements necessary to help you minimize your debugging time. They run the gamut from version control and bug tracking systems, to the compiler and linker settings you need, to the benefits of daily builds and smoke tests.

Although you might need additional infrastructure requirements for your unique environment, you'll find the ones covered in this chapter are generic across all environments. And, they are the ones that I've seen make a great deal of difference in real-world development. If you don't have one or more of these infrastructure tools or techniques set up at your development shop, I strongly encourage you to implement them immediately.