“We must minimize the need to change existing code. For adoption in existing code, decades of experience has consistently shown that most customers with large code bases cannot and will not change even 1% of their lines of code in order to satisfy strictness rules, not even for safety reasons unless regulatory requirements compel them to do so.” – Herb Sutter

  with large code bases cannot and will not change even 1% of their lines of code in order to satisfy strictness rules

> Changing 1% of code on top of that is probably not really that much compared

Quite a few companies have millions and millions of lines of code. Changing 1% of it would mean changing more than 10K lines of code, perhaps even more than 100K. In much bigger code bases, where changing anything has a risk of breaking something — not just because you might make a mistake, but because your program is full of Undefined Behaviour, and changing anything might manifest latent bugs.

Given that, I'm not surprised people say that Sutter quote with a straight face.

Many of my customers are in an industry with a huge C++ code base and it's all under active development. Safety certification requirements are onerous and lead-times for development are long: many are now experimenting with C++17 and C++20 is on the long-term horizon but not yet a requirement. Because of the safety certification requirements and the fact that the expected lifecycle of the software is the order of decades after their products have been released, changing any lines of their code for any reason is always risky. Lives can be at stake.

But this is a multi-billion-dollar industry. If you're working on scripting a little browser "app" for a phone things may be different.

People just don't make mass changes to existing working code. Mostly they cannot. Even if the tooling was available, which it's not, it's also about reeducating their developers, who don't want to or can't change. Plus it'd have to be recertified. It's all cost with no benefit.

Except, allegedly, at Google. But is there any evidence they actually do this, eg. in public code bases? Or is it just hype?

Could be selection bias. Companies (or departments within companies) who are still actively developing their C++ code probably tend to hire more developers and consultants than companies who are doing minimal maintenance on their code base, and that might correlate well with the “two factions of C++” discussed here.

“Our code is an asset” ⇒ code kept up-to-date

“Our code is a burden, but we need it” ⇒ change averse

> Changing 1% of code on top of that is probably not really that much compared

Changing 1% across all modules is a nightmare. Changing one module which is 1% of the code is nothing.

A company that I worked at had a few very large C++ related migrations, and they were all very very expensive.

The first was removing `long` from the code, since a lot of code assumed its size (is it like `int` or like `long long int`?) and as machines were upgraded it caused problems.

The second was moving to C++11/14/17. Most of the difficulty was toolchains on unixen that did not support the new versions of the language, or for which support was incomplete, or for which upgrading to a version with support broke existing builds.

The third was moving to Linux from big iron unixen. As far as I understand, this initiative is still underway. It was already underway in 2011 when I joined the company.

This is a rich company with a large, healthy engineering department. I imagine that most other companies would not or could not bother.

Are you referring to his book written 20 years ago or 25 years ago? "customers with large [C++] code bases" there aren't that many of these. Vendors, government. With code bases that have stewards, not programmers.