After Search Fell Back to Quarterly Releases, Google Found That Tests Were What Enabled Speed

In 2007, Google Search could no longer release monthly. At best, updates were quarterly. The reason was unglamorous: almost every change touched Search's code—even changes to Gmail counted. Release cadence was held back by regressions. Google's response was an organization-wide mandate: every change had to include tests. Later, Search returned to a higher release frequency. The order is worth remembering: testing first became the price of entry, and only then did speed return.

The things Titus Winters discusses in the interview all point to the same engineering ledger. He is a former Google engineer and one of the co-editors of Software Engineering at Google. Gergely Orosz asked him how Google refactored 250M lines of C++ before AI, why Search was dragged down by regressions to the point that it could not release normally, and why CS curricula should be redone. The original interview is here.

Refactoring 250M lines of C++ in the pre-AI era sounds like a compiler project. One commenter replied that large refactors are mainly a problem for people wearing a compiler costume. Another added that at that scale it becomes a tooling and trust problem. Without automated rewriting and tests people believe in, every cross-cutting change gets stuck in review, and release cadence pays for it. Another commenter mentioned Rosie splitting changes into tens of thousands of small changes, with each owner responsible for one piece. That detail is more useful than the word 'refactor.'

The readability program is another layer. Changing code at Google requires two sign-offs. The file or project owner knows the domain. The readability reviewer is a language-certification expert. Google's first engineer, Craig Silverstein, walked every new engineer through their first change. The Java team turned this into a mentorship system, rotating in experienced reviewers. Later, all languages formed formal readability programs. Before Titus left Google, 10,000+ engineers were in readability at the same time. This may be the largest engineering classroom in the tech industry. The problem it solved is very mundane: make review not depend on luck.

The discussion in the AI era is more direct. One commenter said Google's 2007 fix is suited to coding agents: do not merge without tests; tests must fail on the old code and pass on the new code. Once writing code becomes cheaper, tests are the part of a change that tells you whether it works. Another commenter warned that letting one agent write both the new code and the tests yields a test suite that agrees with every bug. This concern is not fancy, but it is fatal.

On the CS curriculum part, Titus was the only practicing engineer on the steering committee for the 2023 ACM/IEEE/AAAI CS curriculum guidelines. He believes the curriculum is outdated and has not substantively changed since around 2000. Testing and verification are important for newcomers, yet are not in the curriculum. His prediction is that if it does not change, CS enrollment may decline, and software engineering programs focused on practical development skills will attract students. One commenter said the course should start with 'take over last year's student project and add a feature without breaking it.' That assignment is closer to work than many algorithms courses.

The hard part of refactoring 250M lines of C++ is not writing code; it is getting thousands of people to believe the change did not break Search. AI makes writing code cheaper, but this part has not gotten cheaper. The book Titus contributed to can be read for free at Abseil.