Continuous rewriting
Introduction
Squirrel presented for discussion the thesis that "Continuous Rewriting" is an emerging theme for software development, a successor to better-known ideas "Continuous Integration" and "Continuous Deployment". The session opened with discussion of the chart and two examples below:
| 2000-3 | 2004-6 | 2007-9 | 2010-12 | 2012- | |
|---|---|---|---|---|---|
| Continuous Integration | Integration hurts, so automate & do more often. - Daily Builds, Ant, CruiseControl | More tools! - JetBrains, Hudson, BuildForge | Adopted by advanced teams - CI books, CITCON | Tool shakeout, standard for new teams - Jenkins | Adopted by late majority? |
| Continuous Deployment | Delivery hurts, so automate & do more often. - one-click deploy, IMVU | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus | General adoption by advanced teams? - CD book | ||
| Continuous Rewriting | Rewrites hurt, so automate & do more often. - DRW (Dan North), Forward (Fred George) | ???? |
Example 1: DRW
- Small, expendable, co-operating components
- Each fit for purpose
- Hard shell, soft centre
- Message = API
- Identifiable boundaries for experiment
References: Dan North talk, Slides
Example 2: Forward
- Small, short-lived apps
- No testing
- Continuous deployment
References: Fred George talk, Slides
Discussion
We discussed and criticised the thesis and examples. Points made included:
Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.
Red Gate use a strategy called "continuous monitoring".
Some strategies for piecemeal rewrites:
- when you get a change request, extract the relevant component and rewrite it
- the Strangler pattern
