Agile FAQs
  About   Past Conferences   Training   Home  

 
Managed Chaos
Naresh Jain’s Random Thoughts on Software Development and Adventure Sports
     
`
 
Microblog Feed
    Previous Feeds...
    Recent Thoughts
    Comments
    Tags
    Blogroll
    Categories
    Archives
    October 2008
    M T W T F S S
    « Sep   Nov »
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
    RSS Feed
    Add to Technorati Favorites

    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.

    [Post to Twitter] Tweet This Post  [Post to Plurk] Plurk This Post  [Post to Yahoo Buzz] Buzz This Post  [Post to Delicious] Delicious This Post  [Post to Digg] Digg This Post  [Post to Ping.fm] Ping This Post  [Post to Reddit] Reddit This Post  [Post to StumbleUpon] Stumble This Post 

    • Share/Save/Bookmark

    2 Responses to “Throwing Away Code”

    1. alex Says:

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

    2. Naresh Jain Says:

      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.

    Leave a Reply


        Licensed under
    Creative Commons License
    Design by vikivix