When new people asked him if he knew C++ his standard answer was "I know enough to know I don't know C++".
How do you even physically do that?
Generous estimate:
1M LOC
18hr days * 3 = 54hrs
1,000,000 / 54 ~ 18,500 LOC/hr
Then replace some large modules with existing 3rd party libraries, and the whole feat sounds a lot more believable.
This is the result of both being able to cleanup & simplify, as well as completely ignoring edge cases and regressions :)
- If you map out the entire system, and understand how all the pieces fit together, you can: make something simpler that fulfills reqs/does the same exact thing; use template metaprogramming to generate the source code for you, instead of writing it by hand
The only issue is very few people will have the skills or the patience to sit down and try to understand metaprogramming. So you won't be able to take advantage of it in most business use-cases (i.e. won't easily be able to find another cog to work on it), despite how powerful it is.
It's like why more people don't work with K (or functional langs, etc.): it's not a simple procedural or OO language, so it's harder to learn -- and harder to get started with.
It is far less impressive than it sounds, because it relies on having an unimaginably bad starting point.
I guarantee you that the starting point for this story was a pile of copy-pasted classes, each of which had some minor tweak, and that the program exposed some combinatorially large number of similar flows. When a bug was fixed, it would need to be manually applied to dozens of classes, and this did not happen, so each of the copy-pasted classes diverged and replicated functionality.
The output of the weekend was almost certainly a simple set of software layers, each with a clean mathematical abstraction, and the composition of the layers expressed all possible flows from the legacy system.
The best example of this I've heard of was with inkjet printer drivers from HP. They used to fork their entire driver stack, including font rendering and dithering, for each printer they released. They produced dozens of models per year. Then they assigned 5-10 full time engineers to maintain each fork of the driver.
After the open source people had already done it with reverse engineered stacks, someone at HP wrote a unified driver framework where the only model-specific stuff was parameterized inputs to the ditherer (DPI, etc) or the actual wire protocol over USB to send the list of dots to put on the paper.
They ended up replacing something like 10,000 engineers with a dozen people or so, and printout quality increased dramatically (though I doubt it was as good as the open source stacks).