Continuous Rewriting

Continuos Rewriting

CITCON Europe 2013 4:30-5:30 pm topic.

Why?

Business people find smart people that write a lot of crappy code fast. The code does the job done, but it really needs to be rewritten. If you have read Joel Spolsky's blog post on how completely rewriting the code is really really (really) bad, then you know it is not what needs to be done.

The speaker found himself several times in a situation to start working on a project that is in a "needs rewrite desperately" mode. What if we could rewrite continuously?

Every week, even if the code is not broken, we rewrite a piece of code. After a while, all code base will be rewritten. We might not use the rewritten code.

One has to invest a amount of time to do that.

You can rewrite a piece of PHP application in Ruby, another piece in Python, and end up with an application that is written in three languages.

If you rewrite, you end up with better code and you understand the code better.

Similar to pair programming, one would invest some time in continuos rewriting, but there are benefits.

How? -Theory

(Insert slide.)

If a piece of software (for example Factplace) has several components in one language with one architecture, single small components (for example, component A) could be rewritten in different ways or languages. The slide shows how component A is implemented in two different languages (A and A').

(Jason promised to add two links here.)

How? Practice

The speaker showed Whooshingby web application that has a slider which determines how much Ruby or Python code the application uses.

How to do it? Find some time every week, find a quiet piece of code (that is not changing a lot at the moment) and rewrite it.