February 2008 Entries
Just by calling a class' constructor, you are tying your code to some implementation details of the class. Since good software uses loose coupling, though, you should develop the habit of providing a static construction method and hiding a class constructor. There are exceptions that prove the rule, however, as noted both in this article and in the comments. Read on to learn how to develop the good habit, and when you should consider breaking it....
Sam Guckenheimer, the group product planner for Microsoft's Visual Studio Team System, has written an excellent book entitled "Software Engineering with Microsoft Visual Studio Team System." The first chapter compares and contrasts Agile methods with the traditional Software Development Lifecycle (SDLC, or waterfall) approach. In this little essay, I summarize Guckenheimer's findings, and sprinkle in some thoughts about how our organization might consider using Agile methods.
Have you ever had difficulty translating a set of requirements into a set of tests? Do you find regression testing to be a major bottleneck whenever you implement changes in your system? (Or do you have quality issues because you forgo regression testing?) Does your development team ever dump complex functionality into a "smart UI" that becomes difficult to maintain and extend? If you answered yes to any of these questions, you should check out FIT (the Framework for Integrated Testing).