- What Is Different about an Agile Project?
- Introduction to Extreme Programming
- Isn't XP Just Hacking?
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Isn't XP Just Hacking?
When Extreme Programming first started to become popular, some people claimed it encouraged hacking.8 We use the word hack here in its original technological sense to describe an approach to software development that is likely to cause problems, such as the following:
- Development starts without considering the business needs or test requirements, so you start writing code without having a clear idea of what value it has to the business or how it can be validated. Nobody reads the specification document because it is too long, full of vague language, and out-of-date; it simply doesn't say what the software must do.
- The architecture is inappropriate for the product you're developing, or the design is flawed in some way, so you sit at the keyboard, writing code in the hope that if you write enough of it, sooner or later you will create something that can be released to the customer.
- Your code doesn't have any tests to validate that it works properly or that it correctly fulfills its purpose, so you spend days, weeks, even months using the debugger to make your software work without it mysteriously crashing or throwing up more defects.
Why XP Doesn't Encourage Hacking
An XP team uses stories to make sure the developers understand what the software must do. The story card is just a reminder, for the real detail of the specification is contained in the executable customer tests (as well as the sorts of Agile models discussed in Section 6). These tests act like a specification language, except unlike formal methods, such as Z and SEDL, the customer actually writes them. Development does not start until the team has fully considered the business needs and test requirements.
The Agile team doesn't spend time producing a rich and complex architecture at a time when people can only make assumptions about what is needed; instead, it tries to defer applying such constraints until they are absolutely necessary, by which time the team may have a better idea of what is actually needed. For example, why decide to use SQL Server at the start of the project when later on you might discover that you need only a flat file? For this sort of reason, an Agile team doesn't do Big Design Up Front (BDUF9), and instead does the design continuously as the code develops using the practice of Test-Driven Development, guided by the sort of Agile models we discuss in Section 6. The architecture is appropriate for the product being developed and the code is backed up by tests that validate that it works properly.
It is hard for us to accept that XP might lead to hacking when teams fully apply its values and practices. XP is a very lightweight approach to software development, but this doesn't mean it isn't highly disciplined. The advantage of it being lightweight is that you can respond more quickly to change, which is an essential requirement for many projects being undertaken in today's business environment. An Agile team expects changes; it makes changes often and has the people, practices, and tools to do it effectively. This is why such teams can start creating working code from the very first iteration, without hacking.