Common Conception Of Agile Missing The Point?
This is a bit of a rant, but I just gotta get it out of my system.
I’m getting frustrated by people I talk to who seem to misunderstand the whole point of agile software development (IMHO).
Different ways of reducing risk
The point with agile, as far as I understand, is to reduce risk and thereby costs by postponing decisions until we have as much information as possible. In older waterfall processes, pretty much everything was decided upfront. That wasn’t because people thought it was so much fun to decide everything up front, but because they believed it to be the best way to reduce risk and cost. Because a bug found just before delivery is much more costly than one found earlier.
Agile, on the other hand, tries to use development practices which enable us to postpone decisions, practices which makes the system easy to change even later in the development process. Thus, the code you write should have two qualities:
- doesn’t force you into making unnecessary decisions, and
- be easy to change.
How to reduce risk the agile way
Quotes such as “You Ain't Gonna Need It” (YAGNI) and “Do The Simplest Thing That Could Possibly Work” (DTST) emphasize the first part — not making premature decisions. But while you can typically find people talking about the second part too, it doesn’t nearly get as much attention in people minds as the first one. Most likely simply because it’s not included in the name, in the mantra. I guess “You Aren’t Gonna Need It, But Do Not Forget To Make Sure Your Code Is Flexible” just doesn’t stick as easily.
Actually ensuring that your code is easy to change requires some work — especially while trying to avoid making premature decisions! It means using things like table driven code and putting abstractions in code an meta-data in configuration. It means thinking about what things are likely to change, and what things are not. It means not assuming too much, since you never know how things are going to be used in the future.
Where many people misunderstand agile
Rules and practices are good, but they are just the means to an end. I find that too many people interpret the agile mantras of YAGNI and DTST too literally. They create solutions which are “simple” and “works” and only includes “what’s needed”.
However, the next day, or next month, when requirements and expectations have changed (as they no doubt will) these solutions prove to be hard to adapt to the new situation. That’s because their developers forgot about the second part, making the system easy to change! And I believe forgetting that is forgetting the very core of what agile is about!
You agree? Got another opinion? How do you ensure you’re code is easy to change?