Programming takes an extreme turn

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 ([email protected]) 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 ([email protected]) is vice-president of delivery services for EDS in Toronto. He is currently project director for Ontario’s Integrated Justice Project.

Would you recommend this article?

Share

Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.


Jim Love, Chief Content Officer, IT World Canada

Featured Download

Previous article
Next article

Featured Articles

Cybersecurity in 2024: Priorities and challenges for Canadian organizations 

By Derek Manky As predictions for 2024 point to the continued expansion...

Survey shows generative AI is a top priority for Canadian corporate leaders.

Leaders are devoting significant budget to generative AI for 2024 Canadian corporate...

Related Tech News

Tech Jobs

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.

Tech Companies Hiring Right Now