Continuous rewriting - Revision history

Douglassquirrel: /* Post-CITCON comments and ideas */

2013-02-07T06:04:23Z

Post-CITCON comments and ideas

Douglassquirrel: /* Post-CITCON comments and ideas */

2013-02-07T06:00:34Z

Post-CITCON comments and ideas

Douglassquirrel: /* Post-CITCON comments and ideas */

2013-02-06T08:57:09Z

Post-CITCON comments and ideas

Douglassquirrel at 08:48, 6 February 2013

2013-02-06T08:48:34Z

Douglassquirrel: /* Introduction */

2013-01-14T05:32:11Z

Introduction

Douglassquirrel: /* Introduction */

2013-01-14T05:31:07Z

Introduction

Douglassquirrel at 18:21, 8 January 2013

2013-01-08T18:21:19Z

Douglassquirrel at 18:05, 8 January 2013

2013-01-08T18:05:59Z

Douglassquirrel: /* Techniques */

2013-01-08T17:54:40Z

Techniques

Douglassquirrel at 22:26, 8 November 2012

2012-11-08T22:26:31Z

← Older revision		Revision as of 06:04, 7 February 2013
Line 130:		Line 130:

	[http://andypalmer.com/ Andy Palmer] drew comparisons with the [http://www.infoq.com/presentations/Micro-Services micro-services ideas] described by [http://www.linkedin.com/pub/james-lewis/2/4b/5b1 James Lewis] of Thoughtworks. Here are some [http://www.slideshare.net/jamesalewis/java-microservices slides on micro-services].		[http://andypalmer.com/ Andy Palmer] drew comparisons with the [http://www.infoq.com/presentations/Micro-Services micro-services ideas] described by [http://www.linkedin.com/pub/james-lewis/2/4b/5b1 James Lewis] of Thoughtworks. Here are some [http://www.slideshare.net/jamesalewis/java-microservices slides on micro-services].
		+
		+	[[Julian Gamble]] pointed to the [http://queue.acm.org/detail.cfm?id=1531242 continuous rewriting of a language] by [http://en.wikipedia.org/wiki/Arthur_Whitney_%28computer_scientist%29 Arthur Whitney].

← Older revision		Revision as of 06:00, 7 February 2013
Line 128:		Line 128:

	An [http://blog.appfog.com/what-the-obama-it-team-teaches-us-about-polyglot-programming/ article on the Obama campaign's software] by [http://www.linkedin.com/pub/luc-perkins/22/7b3/a08 Luc Perkins] suggests that the Democrats used some of the techniques described here, such as combining many small components with a short half-life, though the article doesn't mention how much rewriting they did.		An [http://blog.appfog.com/what-the-obama-it-team-teaches-us-about-polyglot-programming/ article on the Obama campaign's software] by [http://www.linkedin.com/pub/luc-perkins/22/7b3/a08 Luc Perkins] suggests that the Democrats used some of the techniques described here, such as combining many small components with a short half-life, though the article doesn't mention how much rewriting they did.
		+
		+	[http://andypalmer.com/ Andy Palmer] drew comparisons with the [http://www.infoq.com/presentations/Micro-Services micro-services ideas] described by [http://www.linkedin.com/pub/james-lewis/2/4b/5b1 James Lewis] of Thoughtworks. Here are some [http://www.slideshare.net/jamesalewis/java-microservices slides on micro-services].

← Older revision		Revision as of 08:57, 6 February 2013
Line 126:		Line 126:
	* what might a CR advocate say to the points raised by Joel Spolsky in his [http://www.joelonsoftware.com/articles/fog0000000069.html article on rewrites]?		* what might a CR advocate say to the points raised by Joel Spolsky in his [http://www.joelonsoftware.com/articles/fog0000000069.html article on rewrites]?
	Peter also wrote a [http://zsoldosp.blogspot.com/2013/01/continuous-team-switching.html blog post] addressing some of the issues raised in this session and raising a new question: how might CR help teams rotate developers more effectively?		Peter also wrote a [http://zsoldosp.blogspot.com/2013/01/continuous-team-switching.html blog post] addressing some of the issues raised in this session and raising a new question: how might CR help teams rotate developers more effectively?
		+
		+	An [http://blog.appfog.com/what-the-obama-it-team-teaches-us-about-polyglot-programming/ article on the Obama campaign's software] by [http://www.linkedin.com/pub/luc-perkins/22/7b3/a08 Luc Perkins] suggests that the Democrats used some of the techniques described here, such as combining many small components with a short half-life, though the article doesn't mention how much rewriting they did.

← Older revision		Revision as of 08:48, 6 February 2013
Line 119:		Line 119:
	* Team develop rewriting rules, goals, guidelines		* Team develop rewriting rules, goals, guidelines
	* Business receptive to new ideas, driven to change quickly		* Business receptive to new ideas, driven to change quickly
		+
		+	== Post-CITCON comments and ideas ==
		+
		+	[[Peter Zsoldos]] made several helpful comments after the conference; he asked
		+	* what role acceptance tests might play in a CR world (do we keep them or delete them on a rewrite? Squirrel thinks we keep them and modify as needed)
		+	* what might a CR advocate say to the points raised by Joel Spolsky in his [http://www.joelonsoftware.com/articles/fog0000000069.html article on rewrites]?
		+	Peter also wrote a [http://zsoldosp.blogspot.com/2013/01/continuous-team-switching.html blog post] addressing some of the issues raised in this session and raising a new question: how might CR help teams rotate developers more effectively?

@@ Line 1: / Line 1: @@
 == 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". Continuous Rewriting (CR) promises better responsiveness, faster feedback, improved understanding, and simpler code through regular rewriting of every part of a complex software product. For example, what would happen if your team ensured that every line of code in the application got replaced every six months?
+What would happen if your team rewrote every line of code in your application every six months?
 The session opened with discussion of the chart and two examples below:

← Older revision		Revision as of 18:21, 8 January 2013
Line 105:		Line 105:
	* Reduces team [http://en.wikipedia.org/wiki/Bus_factor bus number], i.e. more people know more of the code		* Reduces team [http://en.wikipedia.org/wiki/Bus_factor bus number], i.e. more people know more of the code
	* Simpler, shorter code		* Simpler, shorter code
		+
		+	== Characteristics ==
		+
		+	We thought of these characteristics a system built using CR would likely have:
		+	* Made up of small components (e.g. source code under 10K bytes)
		+	* Components connected by messaging system
		+	* Reduced usage of database, perhaps no database at all
		+	* Deployment in stages - component live but isolated, then side-by-side with existing component, then fully deployed
		+	* Polyglot - components written in a wide variety of languages
		+	* Business metrics monitored, automated actions to address (similar to [http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/ IMVU's continuous delivery system], which automatically rolls back if revenue drops)
		+	* Team develop rewriting rules, goals, guidelines
		+	* Business receptive to new ideas, driven to change quickly

← Older revision		Revision as of 18:05, 8 January 2013
Line 96:		Line 96:
	* Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?		* Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?
	* Will CR-using teams have tacit code ownership or will CR eliminate that ownership?		* Will CR-using teams have tacit code ownership or will CR eliminate that ownership?
		+
		+	== Benefits ==
		+
		+	We brainstormed these possible benefits of adopting CR:
		+	* Code evolves with business understanding
		+	* Eliminate code ownership
		+	* Fast feedback and fixes
		+	* Reduces team [http://en.wikipedia.org/wiki/Bus_factor bus number], i.e. more people know more of the code
		+	* Simpler, shorter code

@@ Line 76: / Line 76: @@
 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:
+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 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." - [http://history.nasa.gov/sts1/pages/computer.html NASA history]

@@ Line 1: / Line 1: @@
 == 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.
+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 through regular rewriting of every part of a complex software product. For example, what would happen if your team ensured that every line of code in the application got replaced every six months?
 The session opened with discussion of the chart and two examples below:
@@ Line 67: / Line 67: @@
 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 ==
@@ Line 79: / Line 81: @@
 [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.