I was looking over some old code that I wrote.  It works, but it's not great code.  I know more now than I did at the time, so I could improve it.  It's not a current project, but it's current, working, production code.  Do we have a responsibility to go back and improve code that we've written in the past, or is the correct attitude "if it ain't broke, don't fix it"?  My company sponsored a code review class a few years ago and one of the major takeaways was that sometimes it's just good enough; move on.

So, at some point should you just call it good enough and move on, or should you try to push projects to improve old code when you think it could be better?

Unless you will be making changes to this "old code" to fix bugs or add features, I wouldn't bother improving it just for the sake of it. If you do want to eventually improve it, make sure you have unit tests in place that will test the code before you start refactoring it.

You can use the "old code" to learn better practices. If you do this, it's a part-time learning experience and you shouldn't expect that code to replace what's currently released or deployed by clients/customers.
