Volume 10 of the Veracode “State of Software Security” report makes one fact abundantly clear: there’s no shortage of security flaws to be fixed in the applications we use every day. So many, in fact, that it’s virtually impossible to address them all, which raises the question: how do you prioritize what to fix?
One enemy when it comes to fixing flaws is recency bias. The report shows if a flaw isn’t fixed within the first month of its discovery, the chance it will ever be addressed falls dramatically – to 10% in the second month and down from there.
What's the real problem? Developers don't want to review or fix old spaghetti code written by someone else.
It's not just that devs don't want to touch old poorly understood poorly documented code; it's also that dev managers often won't let them. You get the 'oh no, that's a key piece of the system, you could break more than you fix' line. It's often already pretty badly broken and over time you get to know particular devs blind spots even if they're no longer around. But true that many developers just want to work on the latest feature in this years hot new development framework. Experience tells you that if you don't want to job hop every six months that you'll get rotated into the salt mines of maintenance at some point and better make the most of it.