Make programs are very good at keeping track of targets, files that need to be built, and the dependencies between targets. But the Make program is only as good as its inputs. If you don't tell Make about a relationship between two files, it wont discover it on its own and it'll make mistakes because it assumes it has perfect knowledge about the files and their relationships.

The goal of this paper is to discuss the levels of our test efforts and bug regression and their outcomes within the span of a project. Developers are better at unit testing as they are closely familiar with the code and testers at system testing as they are better at designing the test settings. Test settings are usually custom designed and fairly unique from place to place. In this paper, the author limits the discussion's specifics to his company's design.

I have seen many Agile projects, particularly those focused on brand-new product lines, struggle with getting their infrastructure up and running. Much of the reason is the time and effort that is needed to get infrastructure established far exceeds the time it takes to start development using an Agile method, effectively the first iteration. Typically the approach used to establish infrastructure is ad hoc and often not always aligned with the needs of the project. Therefore, a task must be identified to establish infrastructure. The question then is, how to best approach the establishment of infrastructure for a project using Agile methods? We do not want to build excessive infrastructure that may constrain us in the future yet we want to establish enough to keep us stable and productive.

Brad Appleton, Steve Berczuk, and Robert Cowham look back at the world on software configuration management for 2008 and make predictions for 2009.