I’ve been talking with a few of my programmers the past few days about the concept of throw away code, asking them if they’ve heard of the concept, or if they’ve thought about implementing it on their teams. All but one of them replied back to me with variations of “what a waste of time”, or “why would I want to code knowing I”m going to throw it away?”.
Spike Solutions:
Extreme Programming defines spike solutions as:
Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build a system which only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story’s estimate.
When a technical difficulty threatens to hold up the system’s development put a pair of developers on the problem for a week or two and reduce the potential risk.
The concept of throw away code is to practice coding to solve a technical problem, or practice implementing various design patterns / practices. When your done practicing throw the code away and either start over, or implement what you’ve learned from the practice session. When you’ve reached the end of your session then throw the code away and start over your next session.
Have a goal for each session. Setting a goal such as learning how to implement the strategy design pattern, finding a solution for a technical / design issue, or testing out a new testing framework will help you stay focused and meet your goal.
Keep your practice sessions short, I like to keep them between 30min and 2hours, but never more than 2 hours. Going past your set time for your session often times works against you and causes you to loose focus on your goal. I’ve also experienced greater difficulty in convincing the business in approving longer session times.
Combining these sessions with pair programming also provides a great means for knowledge sharing with your team members. Whether you need to show a new team member your software library / framework, introduce them to TDD, or learn a new design pattern this is another good tool for you to use to help reach your goals.
So don’t be afraid to throw away your code. In fact I encourage you to implement throw away coding sessions (aka spike solutions) in your team.
Michael Feathers uses this method (in Working Effectively with Legacy Code) when attempting to understand a system before refactoring it to put it under test. I think he called it ’scratch programming’. He will hack into the code he is using applying tests to ascertain system behaviour and throw it away. I think it can be effective and I guess the use case I apply it too most often is fixing defects in complex code. I take the problem, isolate it, produce a proof of concept to reproduce and then I can apply different fixes to it without the worry of any other dependencies interfering.
Comment by John Nolan — May 16, 2009 @ 5:59 am
Another great example of where you can use this practice. Thanks for the comment.
Comment by david.yancey — May 18, 2009 @ 7:58 am
Hi, nice posts there
thank’s for the interesting information
Comment by Mike — May 23, 2009 @ 2:45 pm