No more code rot

A key security component of Windows…has a validity of 15 months and is going to expire in 25 hours.

This is what I read on the blogosphere today and it made think about doing software design. We all hate old code because we’ve grown and learned since the time we wrote it and now think that we’d never make those mistakes again.

Nevertheless, changing code once it’s checked-in to a project can be harder than landing a probe on an astroid. Code moves in and settles down, bringing all its baggage and bad habits with it – we call this code rot because the longer a certain piece of code is in a system, the worse it tends to look or smell when we review it.

What if we couldn’t let this happen though? What if everything we wrote would self-destruct after a predefined amount of time and if we failed to update it, our software would blow up? All traces of the code vanish, all of its history disappears unless someone looks over it and updates something. Small updates would extend the deadline for a little bit and bigger refactors would add prolonged delays.

This might be a novel way of prioritizing bug fixing and performance over adding new features.