Exactly this. I view rewriting a code base, even if I am copy and pasting some things from the existing one a way of either learning or refreshing my knowledge on how the system works.
An added kicker, I have actually gone down this road, and later realized the only thing I needed to do was make a small change to the existing system, so I did just that and discarded the new work.
Business got their new features, delivered on time, the system was still stable and reliable, everyone was happy, and now my domain knowledge has increased significantly so that new features and development or bug fixes will be even faster.
Code does not rot. It gets complicated and starts to look rotten, but that's the hard won complexity of features and bug fixes. To think you can start over and not re-introduce bugs that have already been fixed seems foolhardy.
Re:Software Engineering at Google (2017)
by collinmanderson on Monday January 07, 2019 @02:52PM
(#18849288)
The underlying dependencies (OS, libraries, runtime, compiler, etc) slowly get out of date.
Out of date dependencies can be seen as code rot, regardless of quality/state of the actual code.
(Not saying that it should be rewritten because of that, but I do consider outdated dependencies to be code rot.)
Even if the product/library/framework never changed much, rewrites would still be necessary to keep it going as new generations of programmers shuffle through. Otherwise we wind up with a Verner Vinge dystopian culture of software archeology.