The Latest

Configuration management is complex. As a product evolves, CM gets even more complex, as complexity breeds problems. So how do we continually march our product configurations toward higher and higher quality? You need good people, process, tools, and automation. People define and put the processes in place. Tools are used to automate the processes and to bury the complexity of CM below the user level. Development is a process that takes ideas and turns them into products. There are many techniques and tools to do design and implementation. The right mix is required to effectively develop a competitive product. On the management side of things, the same is true. Application lifecycle management requires the right set of processes and tools to allow the design efforts to be properly leveraged and to yield the best quality.

This article takes a look at how change is more complex within SOA environments, especially when the architecture must deal with the modernization of legacy applications. Then, the author discusses the ways good release management practices help organizations deal with the constant change churn, complexity, and change volume.

Suppose you are faced with creating a Makefile that needs to deal with two files named foo bar and bar baz, with foo bar built from bar ba'.  I've used italics to make clear that these are file names that include spaces.

Afraid of what you're missing by testing only 7 percent of your code? Forget your formal code inspections; Jason Cohen enlightens us on the merits of bringing lightweight code inspection to your organization.

Everyone knows the importance of well-defined functional requirements. We want our products to work, don't we? But how many of us are paying as much attention to defining our non-functional requirements? In this historically focused feature, we learn from past mistakes the potentially disastrous results of inadequately tested NFRs.

In the countdown to a product release, leaving load testing for last is a risky maneuver. In this month's cover story, Rex Black and Barton Layne present a case study of a project on which they adhered to a four-step strategy. By following these four steps, they were able to alleviate those nasty, end-of-project performance surprises.

As one poor German tourist can attest, idioms don't translate. But Chuck Allison thinks programmers should become "native speakers" of the programming languages they use. This includes using and understanding them, idioms and all.