- 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)
|
|
