Sessions‎ > ‎2011‎ > ‎

When to do the rewrite (or if...)

  • Discussing when to do the big rewrite
  • Much of the discussion early on was comparing/contrasting a rewrite, port, and refactor
    • Are you trying to put new features in?
    • Are technologies changing?
    • Someone brought up the Joel Spolsky article on rewriting
  • Not sure why but I wrote "warts created are battle scars"
  • Can you successfully rewrite in pieces
    • Some folks have had experience using this approach successfully
    • There are tradeoffs with both methods (piecewise and big bang)
  • A bit of discussion about refactoring -- when to refactor
    • Gardening model - I'm in here anyway, I might as well pull some weeds
    • Similar to the campsite rule: always leave the campsite in better shape then you found it
    • These both also have downsides 
      • 1) productivity - how to make sure you get everything done you set out to do if you always stop to refactor
      • 2) breaking undocumented functionality. "You don't know about the requirements you satisfied accidentally."  Some customers may depend on that, and while they shouldn't it might still be costly to change.
    • Think of refactoring as a task that I do, as opposed to a task I do when I need to
    • Pulling on the sweater problem
  • What is the role of the BA in all of this?
    • Can explain to the engineer what is done already
    • Successful ones have some domain expertise (former pharmacist, former nurse)