My Stuff
Love
Respect
Admiration
- Leo Brodie
- Avi Bryant
- Alan Cooper
- Steve Dekorte
- Stephane Ducasse
- Doug Engelbart
- Eric Evans
- Brian Foote
- Martin Fowler
- Paul Graham
- Dan Ingalls
- Alan Kay
- John McCarthy
- Steve McConnell
- Peter Norvig
- Niall Ross
- Randall Smith
- Gerald Jay Sussman
- David Ungar
- Rebecca Wirfs-Brock
- ...And So Many More...
My Amps
Links
Archives
- 05/01/2003 - 05/31/2003
- 06/01/2003 - 06/30/2003
- 07/01/2003 - 07/31/2003
- 08/01/2003 - 08/31/2003
- 09/01/2003 - 09/30/2003
- 10/01/2003 - 10/31/2003
- 11/01/2003 - 11/30/2003
- 12/01/2003 - 12/31/2003
- 01/01/2004 - 01/31/2004
- 02/01/2004 - 02/29/2004
- 03/01/2004 - 03/31/2004
- 04/01/2004 - 04/30/2004
- 05/01/2004 - 05/31/2004
- 06/01/2004 - 06/30/2004
- 07/01/2004 - 07/31/2004
- 08/01/2004 - 08/31/2004
- 09/01/2004 - 09/30/2004
- 10/01/2004 - 10/31/2004
- 11/01/2004 - 11/30/2004
- 12/01/2004 - 12/31/2004
- 01/01/2005 - 01/31/2005
- 02/01/2005 - 02/28/2005
- 03/01/2005 - 03/31/2005
- 04/01/2005 - 04/30/2005
- 05/01/2005 - 05/31/2005
- 06/01/2005 - 06/30/2005
- 07/01/2005 - 07/31/2005
- 08/01/2005 - 08/31/2005
- 09/01/2005 - 09/30/2005
- 10/01/2005 - 10/31/2005
- 11/01/2005 - 11/30/2005
- 12/01/2005 - 12/31/2005
- 01/01/2006 - 01/31/2006
- 02/01/2006 - 02/28/2006
Friday, February 24, 2006
Refactoring and Agile
Dave Thomas (of OTI fame, if you don't know who he is, go to his website now and start reading) wrote a great article entitled "Agile Programming: Design to Accommodate Change". In it, he discusses the oft forgotten table-driven design technique. But, the thing that I found most striking was his take on agile:
There in a nutshell is what agile is to me. The goal is not to refactor, but to try to avoid it. Let's face it, refactoring happens because understanding changes and cruft naturally builds. But, our goal should be to avoid it at all costs. Refactoring should be used for unforeseen obstacles. We shouldn't knowingly put opportunities of refactoring into our code base from the start. Let's take Dave's advice and design to accomodate change!
Refactoring improves code, usually increasing the function while reducing code bulk. However, such refactoring or restructuring often forces the application to undergo a complete development cycle, including unit, acceptance, and regression testing, followed by subsequent redeployment. In a large IT or engineering production system, this can be time consuming and error prone.
Agile programming is design for change, without refactoring and rebuilding. Its objective is to design programs that are receptive to, indeed expect, change. Ideally, agile programming lets changes be applied in a simple, localized way to avoid or substantially reduce major refactorings, retesting, and system builds.
There in a nutshell is what agile is to me. The goal is not to refactor, but to try to avoid it. Let's face it, refactoring happens because understanding changes and cruft naturally builds. But, our goal should be to avoid it at all costs. Refactoring should be used for unforeseen obstacles. We shouldn't knowingly put opportunities of refactoring into our code base from the start. Let's take Dave's advice and design to accomodate change!
Comments