Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation – so today, we are introducing Blink, a new open source rendering engine based on WebKit.
— Google Blink Announcement

This announcement highlights a wider, slower iterative systemic approach. While you can be agile in the short term, even the smaller, lightweight product that rose to success in the end is doomed to be bloated. There are various reasons for this, not necessarily manageable and not necessarily avoidable, like for example keeping code written for a different age, hardware and software infrastructure.

Also, it’s difficult to remove a feature once it’s added, so creating something new, different and separate without the “bloated” features is an effective way to manage it.

In this case, history repeats quite often:

• The most famous example is Firefox itself, born as Phoenix as a reduction of the original Netscape Communicator suite. Its lightness and speed won over and revolutionized the web.
• NextStep, now OSX, was born as a lean version of different components (BSD, Mach, etc) that powered the resurgence of Apple.
• WebKit itself was born from KHTML and it was chosen because it was simpler and more manageable.
• Linux was a new kernel focused to be simple and to run only on 386/486 hardware, born on the principles of the Unix and Minix and reusing the existing tools like bash, gcc (and GNU, overall).
• Android is basically a reduced GNU/Linux with a simplified virtual machine on top (Dalvik).

These kinds of “restarts” have a lot in common:

1. Modularity: they had a chance of keeping certain pieces in place while replacing others. This ensures pragmatism and a shorter timeframe to get things delivered.
2. Building on the shoulders of giants: they don’t throw away everything. They remove the existing, get to the core, polish it, and then rebuild outside. They didn’t reinvent everything.
3. Years-long timespan: these iterations happen in the time of years and the fruits of the new steps are again seen in years.
4. Simplification: the change happens to keep things simple, faster, more manageable.

The process overall is interesting and systemic.It happens in timeframes that are of 5 to 10 years (even more if we consider other components that were reused, like GNU in the case of Linux or Unix in the case of OSX).

Some of these project might never even see the light of the day, it’s a form of natural selection, but overall these principles can be seen constantly appearing in successful projects.

This is perfectly aligned on what Joel Spolsky was writing in 2000: don’t rewrite from scratch.