Consider the following scenario: you have a team of software developers building a new Web-based application. The project manger consistently reports that the team is on schedule and that the software will work. The PM’s assurances are emphatic and you have no reason to doubt him or her.

When the software is ready for delivery to the test team you discover that a number of assumptions were made by the developers about configuration items, directory structures, availability of computer resources, file locations, etc. It takes weeks (instead of a few hours) to build a first release of the application in the test environment. This is your first indication that things were not quite as reported.

Then, when the test team finally conducts their first “smoke test” the software performs so slowly that components time out. It will take many additional weeks of development effort to tune the application to provide reasonable performance, and months to make the necessary architectural changes to support long-term use.

How can we avoid this kind of surprise? How can we make sure that the software will work reasonably well when it is delivered to testing? One part of the solution is to deliver intermediate versions of the software to the test team.

Some of Microsoft’s development teams create a “build” of their applications every night. Under this model any additions or changes to the software must be small enough to be completed in a few days and must be added regularly to the working system in the test environment. Problems with new functionality or changed functionality are discovered quickly.

An adaptation of this approach is to pursue almost continuous integration, and build the system multiple times per day. This helps keep the programmers synchronized. Surprisingly, this approach reduces overhead by eliminating integration problems later in the life-cycle.

Kent Beck developed this idea into a lightweight, disciplined methodology for software development, called Extreme Programming. It is designed for use by small teams that need to develop software quickly in an environment of changing requirements. It can be used by start-up companies and by small teams within large organizations, and has the benefit of providing discipline without requiring the infrastructure of a large company.

Extreme Programming is based on a few key principles including simplicity and communication, and consists of 12 basic practices including:

Small releases that are planned and estimated to take about two weeks to deliver. This requires partitioning functionality into discreet packages and demands scope management.

Simple design that produces the simplest program that meets the current requirements. This means that developers do not build for the future. The focus is on providing immediate business value.

Improving the design progressively as the system is being written. This means that the team identifies opportunities to eliminate duplication in the software. Modules may have to be re-written. However, most systems, no matter how extensive their design, need to be re-written at least once during their useful life.

Pair programming in which all code is designed and written by two programmers working together at one PC. Pair programming has been shown, experimentally, to produce better software at the same or lower cost than when programmers work independently.

A dedicated, full-time, on-site end-user who understands the business requirements, can answer questions immediately, and has authority to set priorities. This has a side benefit of not requiring formal specifications that are used primarily as a communication vehicle between users and builders.

To learn more about Extreme Programming, start at www.xprogramming.com. Try applying this approach to your next development project.

Hughes (james.hughes@eds.com) is vice-president of delivery services for EDS in Toronto. He is currently project director for Ontario’s Integrated Justice Project.

Consider the following scenario: you have a team of software developers building a new Web-based application. The project manger consistently reports that the team is on schedule and that the software will work. The PM’s assurances are emphatic and you have no reason to doubt him or her.

When the software is ready for delivery to the test team you discover that a number of assumptions were made by the developers about configuration items, directory structures, availability of computer resources, file locations, etc. It takes weeks (instead of a few hours) to build a first release of the application in the test environment. This is your first indication that things were not quite as reported.

Then, when the test team finally conducts their first “smoke test” the software performs so slowly that components time out. It will take many additional weeks of development effort to tune the application to provide reasonable performance, and months to make the necessary architectural changes to support long-term use.

How can we avoid this kind of surprise? How can we make sure that the software will work reasonably well when it is delivered to testing? One part of the solution is to deliver intermediate versions of the software to the test team.

Some of Microsoft’s development teams create a “build” of their applications every night. Under this model any additions or changes to the software must be small enough to be completed in a few days and must be added regularly to the working system in the test environment. Problems with new functionality or changed functionality are discovered quickly.

An adaptation of this approach is to pursue almost continuous integration, and build the system multiple times per day. This helps keep the programmers synchronized. Surprisingly, this approach reduces overhead by eliminating integration problems later in the life-cycle.

Kent Beck developed this idea into a lightweight, disciplined methodology for software development, called Extreme Programming. It is designed for use by small teams that need to develop software quickly in an environment of changing requirements. It can be used by start-up companies and by small teams within large organizations, and has the benefit of providing discipline without requiring the infrastructure of a large company.

Extreme Programming is based on a few key principles including simplicity and communication, and consists of 12 basic practices including:

Small releases that are planned and estimated to take about two weeks to deliver. This requires partitioning functionality into discreet packages and demands scope management.

Simple design that produces the simplest program that meets the current requirements. This means that developers do not build for the future. The focus is on providing immediate business value.

Improving the design progressively as the system is being written. This means that the team identifies opportunities to eliminate duplication in the software. Modules may have to be re-written. However, most systems, no matter how extensive their design, need to be re-written at least once during their useful life.

Pair programming in which all code is designed and written by two programmers working together at one PC. Pair programming has been shown, experimentally, to produce better software at the same or lower cost than when programmers work independently.

A dedicated, full-time, on-site end-user who understands the business requirements, can answer questions immediately, and has authority to set priorities. This has a side benefit of not requiring formal specifications that are used primarily as a communication vehicle between users and builders.

To learn more about Extreme Programming, start at www.xprogramming.com. Try applying this approach to your next development project.

Hughes (james.hughes@eds.com) is vice-president of delivery services for EDS in Toronto. He is currently project director for Ontario’s Integrated Justice Project.



Related Download
Create a Unique Selling Proposition for Your Global Market Sponsor: EDC
Create a Unique Selling Proposition for Your Global Market

Register Now