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", which promises better responsiveness, faster feedback, improved understanding, and simpler code.
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
Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their "programmer anarchy" model.
Techniques
We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:
Dan North's "Spike and Stabilise" method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.
Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system that checks whether they got the same result and takes appropriate action if they didn't. (Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:
"On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system." - NASA history
LMAX Disruptor and Event Sourcing are models that may be helpful for CR.
