If you've ever raised a Track that was acknowledged as a bug, this article tells you what went on in the background prior to you getting a hotfix or a new version of SAS code. It's interesting reading, plus there's plenty of good practice that we can all use in our own development efforts. David highlights a number of things:
- Effective tracking of defects (through their whole lifecycle)
- The use of a source management system to keep track of versions and releases of code
- Adoption of the Open/Closed Principle whereby code should be open for extension, but closed for modification. Expressed another way: when a single change to a program results in a cascade of changes to dependent modules (e.g. other macros or DI Studio jobs), that program exhibits the undesirable attributes that we have come to associate with “bad” design. The program becomes fragile, rigid, unpredictable and unreusable. The open/closed principle attacks this in a very straightforward way. It says that you should design modules that never change. When requirements change, you extend the behavior of such modules by adding new code, not by changing old code that already works. I wrote about this in NOTE: Coupling, Bad back in May of this year
