Naresh Jain » Agile FAQs Blog » Managed Chaos

Throwing Away Code

After burning my hands several times, I have concluded that

Throwing away code regularly will save a lot of time, effort, frustration, etc in the long run

Also

Throwing away code is an effective and efficient way to achieve Simple Design

Hence I propose, we add “Throwing away code” as a practice under the Simple Design, XP practice.

This entry was posted on Tuesday, October 7th, 2008 at 11:44 PM and is filed under Agile, Design. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

alex

Hi Naresh,
Is there a border between ‘refactor with small steps carefully preserving existing functionality’ and ‘throw away code’?
alex

Hi Naresh,
Is there a border between ‘refactor with small steps carefully preserving existing functionality’ and ‘throw away code’?
http://agilefaqs.com/nareshjain.html Naresh Jain

I would prefer ‘throwing away code’ over ‘refactor with small steps carefully preserving existing functionality’ in the following case:

* Design of the existing code was based on some core entity which is no longer valid.

For Ex: If you are building a conference program scheduling software, you might have started by taking simplest path first or a thin slice through the problem. Doing so one might end up created Speaker, Rooms, Topics, etc classes. Speakers have certain constraints when it comes to scheduling. So does rooms and topics. At some point, it might turn out that its no longer a scheduling problem, its a constraints problem. At this point, I’ve learnt a great lesson, I understand the domain a lot better now and I would be tempted to throw away the code and start fresh keeping constraints as the central thing.

The analogy William Wake likes to use is, building a system using TDD and refactoring is like climbing a hill. Moving up (higher altitude) is making progress. But at times to climb up, you might have to go around or climb down and then climb up again. That’s kind of refactoring. But in some cases, you might get to a point and realize you were climbing the wrong hill (.i.e. there is another hill which is much taller) or you have reached a cliff and you cannot go any further. So you might have to go all the way back to the starting point and climb the other hill.
http://agilefaqs.com/nareshjain.html Naresh Jain

I would prefer ‘throwing away code’ over ‘refactor with small steps carefully preserving existing functionality’ in the following case:

* Design of the existing code was based on some core entity which is no longer valid.

For Ex: If you are building a conference program scheduling software, you might have started by taking simplest path first or a thin slice through the problem. Doing so one might end up created Speaker, Rooms, Topics, etc classes. Speakers have certain constraints when it comes to scheduling. So does rooms and topics. At some point, it might turn out that its no longer a scheduling problem, its a constraints problem. At this point, I’ve learnt a great lesson, I understand the domain a lot better now and I would be tempted to throw away the code and start fresh keeping constraints as the central thing.

The analogy William Wake likes to use is, building a system using TDD and refactoring is like climbing a hill. Moving up (higher altitude) is making progress. But at times to climb up, you might have to go around or climb down and then climb up again. That’s kind of refactoring. But in some cases, you might get to a point and realize you were climbing the wrong hill (.i.e. there is another hill which is much taller) or you have reached a cliff and you cannot go any further. So you might have to go all the way back to the starting point and climb the other hill.