How do you eat an elephant?
One bite at a time.
It’s funny, of course, but it’s true.
What are our elephants?
Rewriting a system, sure.
What about a new UI?
What about refactoring a large component of the system?
All of these are elephants, but there’s an easier way to determine the elephant in your system:
It’s the part no one wants to talk about, or tackle. It’s the part that keeps getting bumped down in priority on the backlog. It’s the part that only one or two of your teammates can look at, since they either wrote it or were trained on it by the people who understood it.
That’s your elephant.
Elephants may not be expensive, but they’re unwieldy. They’re parts of the system you can’t change easily. They are parts of the system — to extend the metaphor — that do whatever they want, whenever they want. They’re the parts of your system that have twitter quotes written about them.
The second-best way to get rid of the elephants in your system is to take them one very expensive bite at a time.
Another way is to develop systems that, by the nature of their construction, lack elephants (or at least adult elephants).
This is what Test Driven Development can offer. It trades elephants for systematized construction. If your project doesn’t need maintenance, or your team doesn’t need an O&M contract, it may not appeal to you, but for the rest of us that have to maintain these IT systems long after they’ve been written, a system without elephants sounds almost… joyful.