Sure--it would need to be a refactor of the foundations of the code base, and not just splitting a method in two or something. If you look closely at the word '

Sure--it would need to be a refactor of the foundations of the code base, and not just splitting a method in two or something. If you look closely at the word 'refactor' though, you'll see it's actually referring explicitly to what happens at the heart of Kuhnian paradigm shifts. Further, the impact of such refactors can certainly be of sufficient magnitude to be identified with a paradigm shift. You can find Stephen Wolfram speaking to this effect in regards to working on Mathematica. My personal experience also fits with the pattern described by Kuhn: because you couldn't think of better primitives initially, you need to introduce excessive complication which functions much like the classic example with circular orbits + epicycles. Then! it occurs to you, some new way of viewing the whole core of your problem; you refactor; ever thing is comparatively smooth as butter. I think part of the reason that isn't so often brought up in typical software engineering blogs or whatever is that developers are not often in a situation conducive to it playing out that way. The only times I've seen it were when I was working with a very deep codebase, as opposed to wide--and it required me to keep the problem regularly in mind for weeks or months at a time before some insight emerged seemingly spontaneously.