Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

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.

  • 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’?

  • 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.

  • 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.


    Licensed under
Creative Commons License