I must be on a bit of an Andy Hunt jag here… A couple of weeks ago he posted this link to Only the Adaptable Will Survive Change. In some organizations, change is like the proverbial third rail - touch it and someone is going to get hurt. Some people think change somehow invalidates what was done before but that’s just not true; making adjustments is a healthy activity. Anyway, there are a few great quotes from the article that I’d like to call out:
developing software is such a complex activity, anything substantive that you leave until later won?t happen, won?t happen well, or will grow worse and fester until it becomes unmanageable. A certain kind of friction increases, and things get harder to fix and harder to change. As with any friction, the only way to fight it effectively is to continually inject a little energy into the system.
How many projects have started with the ideal of testing only to have management say “we don’t have time” shortly after the project gets underway? Or my favorite “just hack that change in, we’ll go back and clean it up after that important demo.” Yeah right. Technical debt accumulates - you either pay it off over time or eventually you are forced to refinance. It’s very tempting to just let it ride, especially if things seem to be working well, but eventually you’re going to have to send a check to the bank (and the dollar amount only gets larger). We can’t let the enormity of the problems intimidate us either, a little bit each day and we’ll get to where we need to be. If we focus on the size of the problem instead of just doing something we’ll never accomplish anything. Agile methods fundamentally get this idea. Tests are written everyday, code is refactored everyday, customers are shaping the product everyday. To use an analogy, it’s a heck of a lot easier to maintain a healthy weight than it is to lose 30 pounds.
Tempting as it may be for some, it’s important to realize that agile isn’t the same as crisis management.
Crisis management occurs when problems are left to fester until they become so large that you have to drop everything else you?re doing to respond to the crisis immediately. This causes secondary crises, so now you have a vicious cycle of never-ending crisis and panic. That?s precisely what you want to avoid by adopting an agile approach.
I’ve been in “fire fighting” style organizations and it really isn’t much fun. You never get a chance to act strategically, you’re forced into tactical solutions. The pressure to just “get any fix in” causes the code to deteriorate meaning the next change will be even harder than it has to be. Quick and dirty becomes the mantra and while some congratulate themselves on being responsive, most everyone realizes there is a price to be paid for that speed.
Change isn’t limited to code though - everything we do needs to evolve as well.
Agile development recognizes the importance of pragmatism, and seeks to adjust everything?the schedule, the design, the features?based on what is really happening. It?s about facing reality and dealing with it, not hiding behind an IDE, PowerPoint presentation or a Gantt chart.
Just because we did something a certain way two years ago doesn’t mean we should still do it that way today. Heck, when Java first came out, we used text editors and the command line, today we use full featured IDEs. That doesn’t mean we were somehow *wrong* 10 years ago. Don’t forget, for thousands of years we thought the world was flat too.
As hard as it can be to change, not doing so is a recipe for disaster.
Sticking to any plan or technique that is no longer appropriate is a guaranteed way to fail. Both the dodo bird and the buggy whip manufacturers learned this lesson the hard way.
It’s important to realize that modifying your approach isn’t an admission of failure - in reality it’s the mature reaction to the world around you. It may not be easy, but the consequences of inaction are far worse than any pain the change may cause.
