Developer

A light discussion on light methodologies

An alternative to waterfall and RAD development processes is starting to emerge: the so-called light methodologies. Why are they light, and why should you care? This article explains.


When you walk around IT offices, the small talk generally concerns the kid’s soccer game the day before or how the hometown football team did, or maybe new computer gadgets and how much technology has changed since you started in the field (even if that was just a couple of years ago). You don’t normally hear people talk about their development methodology. In fact, although everyone uses methodology, it rarely comes up in conversation. (If it does, it is usually derided.)

Development methodology simply refers to the processes and procedures you use to create your computer applications. While you may not use a formal methodology, you undoubtedly use some set of processes. Light development methodologies embrace practices that allow programmers to build solutions more quickly and efficiently, with better responsiveness to changes in business requirements. This article begins a five-part series that will provide insight into this trend and explain why the new methodologies are becoming more popular.

Our old friends: Waterfall and RAD
Most of you know about the two major development methodologies: waterfall and rapid application development (RAD). In the broadest sense, waterfall is the traditional sequential process: analysis, design, construct, test, and implement. RAD refers to any process that tries to accelerate the development life cycle and that generates partial solutions earlier, through an iterative approach.

Those methodologies used to be your only choices. In the last few years, however, a new set of light methodologies has surfaced, including Extreme Programming, Agile Programming, and SCRUM. Calling them methodologies may be a little misleading; they may be better understood as development approaches or even development philosophies.

Many features of these approaches, such as pair programming, are unique. Other aspects, like short development iterations, are RAD concepts that have been taken to an extreme. Although some of these concepts can be applied to both waterfall and RAD development, others are unique to light development methodologies.

Four major aspects of light processes
Light development processes differ from each other in various ways, but they all try to help developers and development organizations build solutions better, faster, and cheaper. (After all, what would be the point if the ultimate results were slower, more expensive, and lower quality projects?) From a true methodology perspective, all the processes tend to be built on the RAD foundation, and they emphasize the delivery of small and simple chunks of code, adding more pieces as you go.

All light methodologies share four general practices:
  • Develop in short cycles. Most people understand that the days of the five-year, monolithic project are over, and have been for some time. Light processes take this to an extreme by stating that the six-month development cycle is over, as is the three-month cycle and maybe even the one-month cycle. Partial solutions should be up and running in a short time, with a tight iterative cycle designed to continually deliver working code that is built up to a final solution.
  • Involve the customer. If you are going to achieve rapid results, the customer must be an integral part of the project team. In fact, the customer should be assigned full-time and co-located in the same physical space as the rest of the team.
  • Value the people. The light processes always say something about how the people on the project should be treated. Typically, the methodologies refer to programmers, but I take this a step further and include analysts, designers, and even the project manager.
  • Strive for simplicity. If you have a choice between building something in a sophisticated way or a simple way, choose the simple way. Requirements, design work, and coding techniques all should be simple.

Characteristics of light projects
It may be true that you can use some aspects of light methodologies on any project. However, some projects are more likely candidates than others. For instance, you probably don’t want to use light processes on large projects with dozens of people. However, some characteristics of these methodologies, such as heavy customer involvement and pair programming, may not make sense for projects that require only a few people. The light methodologies are most successful when the project team ranges from four to 15 people and when there is a strong likelihood that the business requirements will change over time.

Summary
Light development processes did not exist five years ago, but their growing popularity means that many of you will experience them in the next few years. You will see that many of the details make intuitive sense and can be applied to your development work immediately. Other aspects require more of an organizational commitment in their implementation. Some of the ideas look promising, but will need more time and data to prove their worth.

Editor's Picks