If one assumes that bugs are introduced at construction (the writing of the software) then you can use that as a fixed point to determine the cost of bugs based on when they are found. Which, using the original study, would mean that in testing the bugs would be more costly and that in production the bugs would be even more costly.
What is interesting is that it is a function of time and not phase. So, for example, if you were continuously deploying code and a QA found a bug the same day it would effectively be the same cost (assuming everything else is equal) as a code review done by a developer. It would also be significantly less than a bug found several months down the pipeline once your code was finally integrated into a QA environment in a non CD example.
Agreed: When I work on a block of code I am quickest at making changes to it within the hour (as I still have it's design and structure loaded into my brain).
I'm slower to make the same changes after a few days or a week, and even more so after six months.
My experience is that I'm not alone. Well structured code, unit tests, and documentation help - but will never eliminate the work of loading the system into your brain again.
Counterexample: the Debian bug of 2008 lingered in the code base for years before being detected, but the fix was still a one-liner (as was the original bug).
