Should you rewrite your software? Yes! (But only in the right circumstances) | David Heinemeier Hansson AMA Recap | Basecamp 3

The world is flat. The Four Humours. Geocentricism.

These are all examples of paradigms which have since shifted once thoughts moved on.

In a similar way to these paradigms, Joel Spolsky’s writing in the early 2000’s on joelonsoftware.com shaped thinking in the software business – some could say even forming paradigms of their own.

Top of the list of all of Joel’s 1113 articles* is ‘Things you should never do, Part 1’. This article states the worst strategic mistake you could ever make is ‘rewrite the code from scratch’.

David Heinemeier Hansson, creator of Ruby on Rails and Co-Founder of Basecamp, disagrees with Joel. Rewriting should be an option.  

Top ten list from joelonsoftware.com

In the wake of DHH’s Business of Software Conference USA 2015 talk (available here), we had the opportunity to further question David’s philosophy, with the excellent Peldi of Balsamiq, and understand how Basecamp are on the cusp of releasing the second rewritten version of their product Basecamp 3, in the coming weeks.

What followed was a fascinating hour of theoretical debate and practical insight. Below is the video of the hangout, with a summary following further down the page.

Hangout Summary

Theoretically

DHH said ‘the ideas that were held true at the beginning, don’t always hold true today.’ He states his own case as an example, where at Basecamp, they rewrote their code from scratch for the first time 7 years ago – and immediately sales doubled.

David stated that the ‘standard notion’ of a rewrite is one ‘wrapped in technical debt’ – only being an appropriate thing when things are so messed up and stretched by growth that a system is no longer workable. David disagrees with this view and states a rewrite should be an option when on a product level, the best ideas are no longer being the ones leading the product. He states instead of trying to fashion a stingray chair from a table, why not instead build a chair/product that is designed for purpose from the ground up.

This does not mean to say David is purposely goading Joel’s view, he is merely putting rewriting back on the table as a course of action after many years of it being considered the worst thing anyone could do to their software.

David does state a rewrite is not a decision to be taken lightly and it should only be undertaken when the right set of circumstances warrant it – as the work involved is colossal.

Practicalities

How many people work on the Rewrite vs the Existing Product?

It starts out with a small team – you don’t always know what you’re going to build to start off with. David stated he started out with a team of 3, playing around with new ideas. The first stage was actually tweaking the existing code base to try and retrofit it for new features. Once he decided he would be trying to make the metaphorical chair from a table, he knew it would be a good time to rewrite.

So far as resources go, it’s a slow process – You start adding people slowly and methodically. Eventually a point is reached where confidence is high enough to commit more people to the rewrite. The new product still does not take president – the product that is bringing in the money is the most important thing as this is the product with current paying customers.

Eventually there is a tipping point where the new product becomes big enough of a project that the existing systems take a back burner in terms of adding large new features and are simply maintained. David takes the attitude that even after Basecamp 3 has been released, ‘sunsetting’ is not an open – ‘the lights will stay on for as long as people are using older versions of Basecamp’.

What do you do when you are rewriting and write a new feature and are in the middle point between the two? Do you replicate that code in the existing product?

David gave the example of a new text editor they were writing for Basecamp 3 called Trix – the original idea was to put it in both. Once the momentum had switched to BC3, big changes that required huge migrations in Basecamp 2 no longer seemed of value. So in that example it was decided simply not to retrofit this new feature into an old product.

The reality is once BC3 started in earnest, the ambition for BC2 shrunk considerably. It is important you don’t do it too early. Once the new version is getting nearly ready – of course you are going to start thinking it is better than the original. It helps building a level of urgency. Even if you are making a new version of a product, you have to scale back your ambition.

David stated the solution was to be less insecure about your product – not many people really care that much about things changing too quickly. The natural tendency for developers is to be constantly tweaking as it makes a difference to them as they are so close to the product – the movement towards SaaS software has made this possible. However, just because it is a possibility, doesn’t mean it has to be abused. Take ios – that’s on yearly release schedules. Adobe – 18 month schedules. Peldi and David suggested that perhaps the world of SaaS is moving towards this older system of slower, waterfall style releases as developers come to realise the ability to change software is not permission to produce sub-standard products.

How about customer support? How do you know which system people are using, and how do you address their concerns and requests?

One of the first things David said they did at Basecamp was upgrade their support systems. When a request is sent through, meta data is sent with it to further inform the support representative of version number for customers to help aid resolution time.

So far as balancing requests for changes while a rewrite is ongoing – David stated the key is to be working on the customers behalf – not necessarily servicing their individual requests. David used the anology of a door. Instead of peeking through the keyhole, why not open the door and understand the wider context around why customers are requesting certain features. With this approach, David says Basecamp are able to attack vast swathes of problems rather than individual issues.

And for the record…

There are no plans being held back for Basecamp 4. David did say that by acknowledging that a rewrite is possible in the future – he feels much more relaxed about producing and working on his product.

To get invited to Basecamp 3 early see: basecamp.com/basecamp-3-is-coming

*as of 20^th October 2015