So what's new? This is the IT industry: things change rapidly.
Our technology changes; our software changes; we even change our minds. What doesn't change is the way we deal with these technologies, and the ways in which we deal with change itself. Worse than this, our dismal failure rate doesn't change. And the basic rules for developing software haven't changed since the earliest punch card machines.
Change is coming though. A new class of methodologies, called agile methods, promises things you have been trained to believe aren't possible. A paradigm shift is on its way, and it would be wise for you to prepare.
This is the first in a series of columns in which I plan to explore the change in how we develop software. I think it only fair to warn you, up front, that I'm firmly in the extreme programming (XP) camp, and if you don't know what I mean by that, it should all become clear.
XP is a software development process that was designed to meet the rights of customers (a customer being the person who buys or uses the software). Those rights are specified in the Software Management Manifesto. This says that the customer has these rights:
- To know how much work will cost and how long it will take
- To see progress and have a working system providing real business benefit, early in the project
- To change their mind. They should be able to substitute old functionality for new functionality
- To specify priorities
- To be informed of schedule changes, and the right to change things depending on these changes
- To cancel the project at any time and still be left with a working system that reflects their investment up to that date.
Above all else, XP is a human process. It puts decision-making power exactly where it needs to be - in the hands of the software development team.
At a minimum, an XP team consists of developers, customers, a coach and a project manager. A coach is similar to a team leader, but we'll discuss that in a later column. The thing that should jump out at you is that the customers (or a representative sample) should be included as part of the team. We don't mean "part-of-the-team" in an academic, all-encompassing sort of way. We mean, literally, that a customer or two needs to be allocated full-time to the project, and that they should sit with the developers.
This team follows about 12 simple rules, which we'll also cover in future columns. Some of these rules govern how to write code, others govern how to run the project, yet others govern the behaviour and rights of everyone concerned.
What XP does is focus on producing high-quality software, quicker than it can be produced by any other method, at less cost. High quality in this sense means that it should have few defects, and that the cost of owning (read: changing) this software should be low.
Next time we’re going to define a few terms, like failure and success, just to make sure that we’re all speaking the same language. This is necessary, I’m afraid, because when I say that well over 70% of your projects fail, the first thing you’re going to do is try to squirm out of it. You’re going to go straight into denial. You’ll think that only “other people” have a failure rate that high, and that you, and your organisation, fail with only about one in five projects.
When I point out that I was just trying to being nice, that your actual failure rate is closer to 95%, you’re going to just call me a liar … and I don’t want that now, do I?