Difference between revisions of "Continuous rewriting"

From CitconWiki
Jump to navigationJump to search
(chart finished)
(start of discussion)
Line 1: Line 1:
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 this chart:
+
== 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:
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 31: Line 33:
 
| ????
 
| ????
 
|}
 
|}
 +
 +
=== Example 1: DRW ===
 +
 +
* Small, expendable, co-operating components
 +
* Each fit for purpose
 +
* Hard shell, soft centre
 +
* Message = API
 +
* Identifiable boundaries for experiment
 +
 +
References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]
 +
 +
=== Example 2: Forward ===
 +
 +
* Small, short-lived apps
 +
* No testing
 +
* Continuous deployment
 +
 +
References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese 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.
 +
 +
[http://www.red-gate.com 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 [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]

Revision as of 14:20, 8 November 2012

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