Refactoring vs Hacking I stumbled across this old piece of writing from Eric S. Raymond. It turned on some lights for me. Well worth reading. I think that Raymond is half-correct here... Hacking and the various agile development tenets that say "don't do a big spec up front, rather, write the simplest thing that could possibly work and then refactor it into shape as needed" do have a lot in common, but I tend to think of them as having separate goals.

• "Hacking" is more often done for self-satisfaction and pride of workmanship. If there's something wrong with what you've hacked, you're probably also the one who's running it, so you can fix it yourself.
  
• You hack on problems that are interesting to you, you don't necessarily want to be hacking on code that's a customer deliverable, where you'll be asked to support it later.
  
• When you're hacking, you don't write test cases. Or at least, I didn't until recently. Now I do.
  

But there's at least one useful insight in here, that the "hacker ethos" and the "agile manifesto" are saying much the same thing. This is worth thinking about.  ¶ 9:08 PM