Data Acquisition and Online Analysis at the NSCL
Prev		Next

Chapter 5. Best Practices for Building Software

5.1. Introduction

This chapter discusses some techniques that can be considered best practices in buiding systems for data acquisition and analysis that must be shared with other people and groups. The bulk of this chapter will therefore deal with the practical aspects of a very complex field of software engineering, configuration management.

If you are never going to send your software to other people, or are not maintaning a device for other users, you may not need to read this chapter. However much of what we will be talking about specifically in the context of NSCLDAQ and SpecTcl is applicable to the more general realm of software that must be configured to operate under many different environments.

Prequisite for this chapter is a working knowledge of:

bash or other shell scripting.
C and C++ programming
Unix Makefiles
Tcl/Tk programming

If you feel your background in these areas is shaky, or if, as you read, you discover that you need some more background in any of these areas, see the Resources section at the end of this chapter for more information.

If you want to delve further into any of these subjects, again see the Resources section at the end of this chapter.

This chapter will cover the following material:

The goals and principles of building systems based on the practices described here.
How to isolate items in your software which might change from those that are fixed.
How to build software that can be maintained over the long run.
How to build rollout systems that deploy your software into specific experiments without losing control over quality and maintenance issues.
How to build your software so that it can integrate as a part of a larger experiment involving other software from other sources.
Finally we list some resources for further study in the tools we describe in this section

	Disclaimer
	I make no claim that all of my software adheres to every one of the practices and techniques described here. The reasons my own software deviates from the practices in this section are two-fold. A practice represents something I wish I had done on a system that is large enough or established enough that to adopt this practice now would have too high a cost for either myself or the users of the software. A conscious design compromise was made because in my judgement, the cost of implementing the practice far outweighed the gain. This second reason should be stressed. Each practice described has a cost. You must use your own judgement and common sense to determine whether or not the adoption of a practice will provide you more gain than the cost of the technique.

Disclaimer

I make no claim that all of my software adheres to every one of the practices and techniques described here. The reasons my own software deviates from the practices in this section are two-fold.

A practice represents something I wish I had done on a system that is large enough or established enough that to adopt this practice now would have too high a cost for either myself or the users of the software.
A conscious design compromise was made because in my judgement, the cost of implementing the practice far outweighed the gain.

This second reason should be stressed. Each practice described has a cost. You must use your own judgement and common sense to determine whether or not the adoption of a practice will provide you more gain than the cost of the technique.

Prev	Home	Next
Other resources	Up	Goals and Basic Principles