Choosing a Methodology

---

A methodology is a framework for constructing software. I almost decided not to mention methodologies at all in this book. That’s because they’ve been a source of much debate over the years. This debate has often generated more heat than light; people seem to feel compelled to defend their own preferred methodology, if not to the death, at least to the point of extreme discomfort.

Using Microsoft Project

Developers sometimes get seduced into trying to use Microsoft Project for software project management. After all, it’s a dedicated project-management tool, and it comes as part of your MSDN subscription, so why not?

Because it’s overkill, that’s why not. Microsoft Project is made for managing huge projects— say, building a new dam or office park. Project (and other high-end project-management software) is at its best when a project involves a complex web of interdependencies and pools of interchangeable workers. Neither of those tends to be true for software projects. The dependencies in a program are usually pretty obvious, and software construction seldom proceeds along more than two or three main paths at once. And developers are certainly not interchangeable; Mary won’t be able to debug Bill’s code efficiently, and adding a database developer to an overdue Internet integration project is unlikely to speed up its delivery.

For very large projects, you may find something like Project necessary. But in that case, you have gone beyond the scale that I’m concerned with in this book. For small applications, take a look at the other programs I mentioned earlier, and stay away from Project.

Nevertheless, there’s a lot of good stuff in the various methodologies that have been proposed over the years. As a developer, you can’t afford to turn your back on the wisdom of your peers. But you probably don’t want to spend years learning about methodologies either. So in this section, I’m going to present a very personal and biased view of methodologies by mentioning three schools of thought that you should be aware of.

For a more thorough review of software methodologies, see Steve McConnell’s Rapid Development (Microsoft Press, 1996).

The Waterfall Approach

Much of the early work on methodologies came from organizations such as NASA’s Software Engineering Laboratory (SEL) and Carnegie-Mellon’s Software Engineering Institute (SEI). The focus here was on rigorous methods for developing large applications in an age of relatively primitive software tools.

The methodologies to come out of this era were relatively bureaucratic, emphasizing lots of planning and documentation. At a time when assembling a working program out of small routines was a heroic task, that made sense. And with the proving ground for much of the work being the manned space program, where errors in software are measured in human lives, a heavy process was affordable.

These early methodologies were characterized by a “waterfall approach,” in which activities flow smoothly into one another. At the top of the waterfall, you start with requirements analysis. From there, the project flows downhill through preliminary design, detailed design, implementation, and system testing, coming to rest in an acceptance testing phase. At that point, the software is finished, and the development team goes on to something else.

If you’re interested in this set of methodologies, NASA’s SEL has a large selection of documents online at http://sel.gsfc.nasa.gov/website/documents/online-doc.htm. Manager’s Handbook for Software Development and Recommended Approach to Software Development in particular will make for interesting reading for those with a sense of history.

Iterative Approaches

As time went on, waterfall methodologies were found to be a poor fit for the way that software development was actually carried on in real organizations. Part of this mismatch was the effect of better tools. Moving from mainframe work, with decks of cards submitted to run overnight, to compilers and editors that actually ran on the desktop made it possible to speed up the software development process immensely. The compile-run-debug cycle decreased in length from days to hours and then minutes. As it became easier to try out ideas before designing them in detail, more exploratory coding went on. The different phases of design, implementation, and testing all started to muddle together.

In response to these changes, some iterative methodologies came to the fore in the software industry (or at least in that part of it concerned with software for personal computers). Two of these are the Rational Unified Process, or RUP (developed by Rational Software, which is now owned by IBM) and the Microsoft Solutions Framework (MSF). You can find their respective home pages at http://www-3.ibm.com/software/awdtools/rup/ and www.microsoft.com/technet/itsolutions/tandp/innsol/default.asp.

Iterative methodologies are characterized by an explicit representation that project phases such as development, testing, or planning may be repeated many times in the course of a project. Figure 1.4, for example, is a schematic diagram of the current version (3.1) of MSF. Although it includes many of the activities you’ll find in classic waterfall models of software development, the key feature here is that the process loops back on itself. When one iteration of deployment is finished, another iteration of envisioning is just beginning. A large project might move through this cycle half a dozen times before release.

Figure 1.4: Schematic diagram of the Microsoft Solutions Framework

Agile Approaches

In the mid- to late 1990s, a new group of methodologies started garnering increasing attention. Generically referred to as agile methodologies, this group includes such processes as Extreme Programming (XP), Scrum, and Crystal. In some quarters these developments have been greeted with relief; in others they’ve been condemned as a complete abandonment of any sort of reasonable process control. One reasonably fair overview is Martin Fowler’s essay “The New Methodology” (www.martinfowler.com/articles/newMethodology.html#N4001F4).

The agile methodologies look at the transition from waterfall to iterative methods and continue the trend. If faster cycles are useful, why not reduce the cycles to weeks or even days? If bureaucracy can be cut down, why not cut it out entirely? These are attractive notions, especially to developers who like rapid development and dislike bureaucracy.

The best known of the agile methodologies is XP. XP is a collection of practices, some of which (such as pair programming, which involves having two developers work together to write code) are quite controversial. Nevertheless, it’s also the site of much of the most interesting research in software development being done today. You should at least read Kent Beck’s slim book Extreme Programming Explained (Addison-Wesley, 2000) to get an idea of the issues here. On the Web, check out the Agile Alliance (www.agilealliance.org/home).

Settling on a Methodology

So which methodology should you choose for your software development work? Frankly, I don’t think that you really need to choose. Instead, I recommend what might be called a metamethodology:

RULE

Take what works for you and leave the rest.

I’ve tried to exercise this philosophy in writing this book, and in my own software development. For example, estimating the costs of an entire project up front is a practice from waterfall and iterative methodologies, where it’s assumed that you know where you’re going when you start. Agile methodologies don’t think much of this approach, preferring instead to deliver small chunks of functionality until time or money runs out. On the other hand, test-driven development (which you’ll meet in Chapter 5, “Preventing Bugs with Unit Testing”) is straight out of XP; I find it a useful practice even without any of the other XP methods.

Inevitably, as you write more software you’ll learn which tools and techniques work for you. Over time, this will result in your own personal methodology. If it lets you deliver working software, don’t let anyone tell you that you’re doing it wrong.

---