How to eat an elephant

How do you eat an Elephant? One bite at a time. It’s such a classic, it has become a cliché. I have used it in many presentations without even thinking about it. It is used by project teams everywhere as a metaphor for breaking up a really large problem into smaller pieces. To convince the team not to bite off more than it can chew

When a team is embarking on an elephant-sized project, it’s easy to make everyone feel better by stating that it’s going to be ok – we’ll be eating the elephant one bite at a time. I heard that story many times in the past and it feels that we are not using that metaphor properly. It is easy to forget, as a member of the project team, that we’re not eating the elephant. We are merely cooking it.

The person that has to eat the elephant is your user. Not only does the team have to cook that elephant one bite at a time. They have to make sure to feed those small bites to your users one at a time.

If you spend 3 years rewriting a piece of legacy software. Your team might have cut up that elephant and cooked it in small batches. But, by the time you’re ready to release that rewrite after 3 years, you are serving a large portion of that cold, stale elephant to your users. They have to live with all the changes, all the new bugs, all the business logic that didn’t get moved over, and all the features that didn’t make the cut. They have to eat the whole elephant at once.

There are plenty of stories that make the argument that large software rewrites are rarely a good idea (here, here, here). One argument that often gets forgotten is that software rewrites represent a large disruption for users. In the case of enterprise software, this is the tool that they are forced to use day in, day out.

Software needs to evolve and eventually, needs replacing. Refactoring is often proposed as an alternative to rewriting but it is only one of many techniques. In general, the concepts that scaffold these techniques also have a benefit for our users. They usually aim to effect change in small, testable increments.

When changes come in a steady stream of valuable improvements, users can eat and digest that change. If you make a mistake and a change is not very valuable, it is easier to rollback or course correct if it is small.

This story was also published on medium.