Material for this article has been excerpted from Scott Ambler and Pramod Sadalage's forthcoming book Refactoring Databases: Evolutionary Database Design (Prentice Hall PTR, February 2006). See www.ambysoft.com/refactoringDatabases.html.

Automation is an essential component of agile development. This is especially evident where testing is concerned. At the end of each iteration, sprint, or release, our working product is expected to be of shippable quality, even in its embryonic stages. Traditional development methods push system and acceptance testing to the end of the release cycle. This back-end testing is typically manually intensive, possibly supplemented by the use of semiautomated tools.

It is not uncommon for an agile software development team to share out DBA responsibilities among developers on the team. While this is often satisfactory, situations can arise during development cycles that are best dealt with by bringing in a specialized, dedicated DBA resource.

Traditional development of applications over databases can be a slow, ineffective, and brittle effort. Many of the problems stem from poor communication between stakeholders. However, by following agile techniques, developers can create high-quality code that they can rework in minutes to react to the evolving understanding of their stakeholders. In this article, I take this insight a step further.

Yes, it's true that the discussions we have in our industry about methods often have the quality of dueling religious fanaticisms. So let's hit this one head-on: evolution versus intelligent design.

There's an old saying: "If you don't know where you are going, any road will get you there." This is especially true of process-improvement initiatives. Most change initiatives start out with a clear sense of goal (better, faster cheaper) yet stumble when all the energy and effort seem to fail to produce lasting change. How does the implementation fail if the vision seems clear?

Central and Eastern Europe (CEE), 1 including the Czech Republic, Poland, Hungary, Romania, and Latvia, has been ranked among the top locations for outsourcing IT work. 2 Yet knowledge of sourcing to this region, with its advantages and disadvantages, is limited and rather vague. In most books on IT sourcing, these countries appear under the heading of "other," following India, China, and Russia, and little information is provided about sourcing to these locations [7].

Central and Eastern Europe (CEE), 1 including the Czech Republic, Poland, Hungary, Romania, and Latvia, has been ranked among the top locations for outsourcing IT work. 2 Yet knowledge of sourcing to this region, with its advantages and disadvantages, is limited and rather vague. In most books on IT sourcing, these countries appear under the heading of "other," following India, China, and Russia, and little information is provided about sourcing to these locations [7].

Nearly two-thirds of the world's Web sites run on the Apache HTTP Server. The wildly successful Apache server was not the brainchild of a big software powerhouse such as IBM, Oracle, SAP, or Microsoft. Apache came into being because a group of individuals cared deeply about developing really great technology. Apache tells the inspiring story of the HTTP Server's development on its Web Site (see www.apache.org):

We're always complaining about the business technology "alignment" problem -- though my preference is to redefine it as a "convergence" issue. However you view it, it's time to revisit the ways to better integrate our business and technology planning and decision making. Let's focus on the financial basics.

The literature of software development and project management "problems" is rife with descriptions of the dreaded "scope creep." Projects take too long because customers are always changing their minds and developers find cool new features to add. However, there is a big difference between scope creep, which is a problem and to be avoided, and the necessity of responding to business changes and the evolving requirements.

Although mobile technology is still young and has limitations, it continues to create novel applications and new business models, "mobilizing" and refining business processes. Mobile computing is attracting lots of interest as stakeholders come to realize its value, and it is empowering us in myriad ways. Quietly, the mobile revolution has begun!

Although mobile technology is still young and has limitations, it continues to create novel applications and new business models, "mobilizing" and refining business processes. Mobile computing is attracting lots of interest as stakeholders come to realize its value, and it is empowering us in myriad ways. Quietly, the mobile revolution has begun!

Risk management plans, by virtue of their definition as a component of the project management plan, are too often perceived as being project specific but limited to an internal project focus. As a result, project risks that are identified frequently tend to be constrained to technical/resource issues within the management scope of the project/program manager (PM).

Many companies are still debating their decisions to ship projects abroad in light of the negative connotations offshore projects may have to onshore teams, particularly companies' full-time employees. A number of my recent engagements have revealed an aspect of the sourcing challenge, which I call the "ego factor." In this Advisor, I will explore why this behavior occurs in many companies today, explain the risks associated with the phenomenon, and include some ways to avoid such pitfalls.

Many companies are still debating their decisions to ship projects abroad in light of the negative connotations offshore projects may have to onshore teams, particularly companies' full-time employees. A number of my recent engagements have revealed an aspect of the sourcing challenge, which I call the "ego factor." In this Advisor, I will explore why this behavior occurs in many companies today, explain the risks associated with the phenomenon, and include some ways to avoid such pitfalls.