 When the Hubble Telescope was launched
into space it had a mirror built to the wrong specifications. It wasn't until the telescope was fully deployed
and in the hands of its customers that the problem was discovered. A satellite's customers can't try using it until
after it's in outer space, but why do we do this with software?
What if you walked into an electronics
lab and saw work benches covered in old appliances? Would you keep that huge old TV with the quaint little round
picture tube because it still had a good power supply? Would you keep an old AM radio because it was useful as
an RF generator? You wouldn't because your work bench would be so cluttered you couldn't get anything done. But
this is exactly what we do with software.
The Zilwaukee Bridge over the Saginaw
River needed to be built in a hurry. The bridge |
was built up from both banks of the river to meet in the middle. But when they got to the middle one side was three
feet higher than the other. When half of your project is on one side of a river and the other half is on the other
you can't integrate your project until the very end, but why do we do this with software?
Extreme Programming (XP) was designed
in response to these kinds of questions. XP was based on observations of what made computer programming faster
and what made it slower. XP is an important new methodology for two reasons. First and foremost it is a re-examination
of software development practices that have become standard operating procedures. And second, it is one of several
new lightweight software methodologies
created to reduce the cost of software. XP goes one step further and defines a process that is simple and enjoyable. |
