« Back to home

Things Google practices that your company doesn’t (part 2)

Episode 2: Embrace Software Rewrites

Joel Spolsky’s essays are legend. His collection of posts on his blog “Joel on Software” in the years from 2000 onwards have been very influential in the development community, not only because of their engaging writing style, but because they set clear directions for tech companies. One specific dogma he successfully implanted in my head was: “Never ever do a complete software rewrite” (You can read it here, please return afterwards). This probably is still very true today, because

“when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time”.

Let’s stress this dogma.

From scratch

In contrast, Google does indeed embrace rewrites. The basic assumption being that the world is changing so fast around a product that a rewrite facilitates to achieve better improvements at some point.

That doesn’t mean that Joel was wrong and rewrites are always beneficial. It still isn’t a good idea to rewrite a product just for the sake of changing underlying technology, or for minor improvements. And Google also states that rewrites come at “substantial costs”. To be honest, it’s very important to note that Google has a very elaborated software development process with lots of top engineers. Most companies will struggle to come near that level of software engineering – including yours truly.

On the other hand, software which has matured by going through many evolutionary cycles becomes harder to change over time, regardless of what you invest in maintenance and refactorings. Together with changes in basic business needs (for example from an installed product to a Software-as-a-Service model or from 1.000 to 100.000 users), a judgement to do a rewrite might be justifiable.

Fergus Henderson states in Software Engineering at Google (pdf):

Most software at Google gets rewritten every few years.

In a short section about software rewrites, he motivates rewrites from a business perspective:

“In a period of a few years, it is typical for the requirements for a product to change significantly, as the software environment and other technology around it change, and as changes in technology or in the marketplace affect user needs, desires, and expectations.”

Rewriting Google Search

To be honest, if your company is not primarily in the software business, this probably is not applicable. For Google, this is definitively true. What is their most important software? Of course, the search engine. It’s a good example how they innovate over the years, by getting faster in responding, picking up changes to content sooner, or providing more relevant representations of results. And indeed, according to Urs Hölzle (from: “The Datacenter as a Computer”, Second Edition):

“the core of Google’s search services has been re-implemented nearly from scratch every 2–3 years”

He goes on emphasizing that at Google,

“[…] architects can consider the possibility of signicant software rewrites to take advantage of new hardware capabilities or devices.“

Rewrites result in a higher development effort, but if done right, can save costs in production, by better utilizing available hardware, in the end.