« The problem with wearing many hats | Main | "Give a man a fish, feed him for a day »
February 21, 2006
I write s**t code... therefore I refactor
Or to be more precise, "I write s**t code the first time, therefore I refactor".
I find this admission of imperfection very liberating and a good way to explain to people why refactoring is important.
After all, can anyone honestly say that the first time they attempt anything, the result is a study in perfection? Or is it more likely a haphazard cludge of elements that just happen to achieve the desired result?
Posted by Andy Marks at February 21, 2006 06:41 AM
Comments
Only one thing to say...
"Utility.java"
;-)
Posted by: Jon Eaves at February 21, 2006 09:32 AM
Nicely put. I have often felt pressured to produce beautiful code from the outset. I've never enjoyed this pressure. I love to have a go and refactor.
Posted by: Daragh at February 21, 2006 05:46 PM
There is a risk here. You check the smelly thing in and those less experienced on the team apply what they consider good code reuse principles via cut-and-paste. Potentially you've got a sewerage farm on your hands.
Re-phrasing your title somewhat, perhaps you mean 'I hack... therefore I refactor' (no pun intended).
On most occasions I start on a card I approach things a bit differently:
* Refactor whats there to make my functionality fit nicely.
* Start sounding out a domain driven design - design discussions/pairing and discussions with analysts all help in forming a better design. Short, sharp, testable object responsibilities become clear. While implementing this design (TDD'd of course) I usually get quick feedback about object collaborations that work and don't. Guiding me through all this is patterns.
I guess that approach is more intentional in forming a domain-driven result (where the world drives the design) rather than a hacked approach where the design is accidentally formed and more inward looking/code driven.
Then again, if you don't care about being domain-driven, I guess the essential point is employing the approach that will get you to your end goal of (hopefully) logical, focused, reusable and tested objects. Each has there own way of getting there faster.
Posted by: blondie at February 21, 2006 10:44 PM
One thing I forgot to mention; your tactic is obviously an important part of a 'spike'. Although, that code should never see the delights of repositories like ClearCase. As Brooks says, 'plan to throw one away'.
Posted by: blondie at February 23, 2006 11:18 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)