Also, do you do anything to reduce that amount?
Hopefully, 30%-40% debugging of 15-20 million lines is not done all in one sitting.
Changing to an embedded OS, say kontiki OS under 5,000 lines of code, would make for debugging only about 1,500 to 2000 lines, or about a 10,000 fold reduction by dropping 10's of millions of code libraries.
On the other hand, first recorded bug was pretty easy to see/fix. https://www.nationalgeographic.org/thisday/sep9/worlds-first...
Back in the day, when soft-ware was wool via jacard loom, finding issues introduced by bug(s) (aka month holes) was a true enlightening/loominating process -> shine light behind woven wool cloth & look for the light spots. Of course, fixing the bug issue(s) meant breaking out the crochet needles to mend the problem. Pearl was taken pretty seriously then.
short take: even if https://hackaday.com/2021/03/08/laser-zap-that-mosquito/ works 100% of the time for 100% of the bugs; the unseen bugs will still make it through.
I don't write much code but it is often computational and mission-critical so it's easy for me to say the vast majority of my time is spent testing. Whether seemingly-suitable code requires a few hours or a few dozen hours to write, it's still going to have to seem to work and then be tested for hundreds of hours, during which time when a defect does appear it may not even require an hour to fix.
So if I consider testing to be a part of the debugging process, it's 10% developing and 90% debugging. Or worse.
But if I accept the testing as part of the development process, the relatively minor bugs that do turn up afterward end up like 10% debugging and 90% development or better.
Well what if you were calculating orbitals at NASA with your slide rule one day when they brought in the first digital computer you ever had a chance to operate?
It was already widely recognized this was going to speed up calculations and make them more accurate by orders of magnitude, that's why they got the mainframe to begin with. Brand new in the package, the full unboxing experience.
Then you walk up to the machine so you can put in some of your data to see what comes out.
Why there's zero lines of code in place waiting to give you what you want!
That's one of the worst bugs you can get.
The only way to fix this kind of bug is to go from zero lines of code to some finite number greater than zero.
Later when there is suitable NASA-quality code that has been very thoroughly vetted then successfully deployed in mission-critical situations, outperforming all alternatives, there appears an anomalous defect anyway which can only be corrected by editing the code to account for the anomaly.
Now that's a bug of a different color.
Often accompanied by emergency action necessary.
Although how bad of an emergency was it to begin with when the computer wouldn't even do what the slide rule could?