REWRITE – notes from David Heinemeier Hansson talk at Business of Software 2015

I’ve taken few notes during the Business of Software (2015, Boston) talk given by David Heinemeier Hansson (Basecamp, Ruby on Rails fame) on the topic “REWRITE”. It was such an excellent talk, I just wanted to elaborate my notes so that it will make sense for me after few weeks.

David Heinemeier Hansson

The main essence of David’s talk is all about, as part of your growth should you go and rewrite your software from scratch or evolve your current product gradually keeping your current paying customers in mind. His talk mainly focused around 10+ years of running Basecamp and their recent effort in building version 3.0.

Idea of Transcendent software

It’s a great analogy to think about your software as physical object. Most of the time people do not give same respect to the software since it’s not a tangible asset, which you cannot touch and feel. But if you start thinking of your software as a physical object it will change the whole perception. Think  about a table or chair, when you are choosing it no one likes to buy a crappy looking table or chair. You wanted it to look good, you wanted the colours to be perfect, shape should be perfect and so on. If you bring the same perception to your software then the way you think about it will change completely.

Need to measure the cost of change VS value of change

David referred to the famous article by Joel Spolsky about “Things you should never never do”, where it’s generally not a good idea to scratch your legacy software and thinking about starting again. This will be one single worst strategic mistake you’ll ever make. Netscape did this mistake by deciding to rewrite their software from version 4.0 to 6.0 (never releasing 5.0), basically no innovation for 3 full years!!.

You always need to measure the cost of change vs value of change. If it cost you $10 to build a feature but the real value for the customer is only $8, it’s better off not to make that change.

Builders normally fall in love with their creations

In general developers fall in love with their creations and treat them like a teddy bear, they are so attached to it. But in reality the customers view your software similar to a fax machine. There is nothing sexy, it’s just used to get things done. The job of the fax machine is to send and receive faxes, that’s it. No one falls in love with the fax machine. Software for lot of people simply mean getting things done. When people move from job to job or position to position, the usage of the software might become redundant. In the case of the fax machine, it will be something like “I’ll use your fax machine, if I need to send/receive any more faxes, but now we have switched to emails, we no longer need your fax machine”

Compete with your very best ideas

Successful software is like golden cuff, in general once you have paying customers and the profits are coming gradually you are reluctant for a change or sceptical about taking features away. You must be prepared to make changes at the hardest possible time, when things are extremely good, if you wait till it goes bad, then it’s too late. Be prepared to compete with your very best ideas, it’s generally a bad practice to just ask few customers and work based on their feedback, they generally do not represent the whole population. If you go down this route you end up building a solution to a customer(or customers) not a world class product.

Sun setting the old version

You have to honour your legacy. In general killing an existing product (or sun setting in a nice way) generally doesn’t transition your current customers to newer versions, instead it will take them back to the market for shopping. In the later speech Rich Mironov highlighted the same issue, when Sybase decided to sunset their current version not thinking about the cost of change to their customers, customers moved to Oracle instead of moving to the new flashy version of Sybase.

Do not force customers to use new versions, let them continue using the current version however long they want and let them move to new version in their own pace. Basecamp 3.0 doesn’t have a import functionality, if customers want to use the new feature they can use it for new projects. The idea behind building a new version is mainly for new customers, existing customers are not targets for new customers. It’s not about forcing all of your current customers  into new versions. Customers would have spend years working on your software, setting up their system etc, it doesn’t make sense to force them to move.

Do not sunset your current version. Google Reader is a classic example, millions of users were relying on it for news reading, all of sudden Google decided to kill it. It’s not very nice from a customer perspective. Google was able to get away, but it will not be the same for all of us.

May be version 1.0 or 2.0 is over, you lock it down. Build 3.0 and let customer move there at their own pace. If they are happy with 1.0 or 2.0 let them continue using it. Basecamp have done the same thing for their Ta-Da list, they gracefully retired it https://basecamp.com/tadalist-retired. You cannot subscribe as a new user any more, but if you have an account you can continue using it.

Conclusion

I have few key takeaways from the excellent talk given by David

1. Think about your current customers : Look after your legacy code and current customers, they are very important. You don’t want them to go around shopping.

2. Bring new versions without effecting existing ones: It’s essential to bring changes to your software periodically, you need to compete with your best ideas. But make sure your new versions are not killing your current ones.

3. Measure the cost of change: Question yourself constantly, whether the change is essential. It’s important to understand the cost of change vs value of change.