Should I go back and fix work when you learn something new/better?

Question

Considering that we're all constantly learning, we've all got to come across a point where we learn something just awesome that improves our code or parts of it significantly.

The question is, when you've learned some new technique, strategy or whatever, do your or should you go back to code that you know works, but could be so much better/maintainable/faster/generally improved and implement this new knowledge?

I understand the concept of "if it ain't broke, don't fix it" but when does that become losing pride in code you've already written and what does it say for refactoring.

Answer 1

Do you have good unit test coverage? If you do and you are confident you can make the change without breaking anything, then why not?

I'd only do this if I was certain the "improved" way was actually better.

Answer 2

Personally for me it's a time thing. If I learn something "new and awesome" then I make a mental note to implement it in any new code I write going forward.

Trying to implement this in old code is both time-consuming to change the code, but also to fix any issues that may crop up later down the line because of the change I've made. Trying to explain to my boss what went wrong in these cases is extremely difficult as he's not a programmer and doesn't understand the pride we programmers have over the code we write.

However, if I do go back and review old code because I've got to change something (fix an issue, implement a new feature etc.) and that code makes me think (ouch, what WAS I thinking?) then yes I change it, because it's something I'm working on anyway.

Answer 3

Yes, if time allows. Usually it doesn't.

Answer 4

Good question and one I often think about. As programmers evolve, there will be less around to maintain legacy systems and so it's important not to let your systems become too old otherwise it will become expensive to maintain them in the future.

Rewriting an entire system is not a task to be taken lightly though. Years of small bug fixes here and there will be difficult to capture starting from scratch again so a lot of care is needed.

If you can reduce 1000 lines of code down to 100, I'd suggest it's worthwhile doing. If it means implementing a whole new framework to achieve this, I'd think otherwise until the benefits far outweighed the downsides.

Answer 5

There's no hard and fast rule, but in general the way I've approached is: If its for a personal project, by all means. If its on someone else's dollar, then generally you hold off on fixing it until the client wants the benefit of increased maintainability/performance that you'll be delivering or until you need to touch that code to make other alterations anyway. Whatever the case, try to make sure you've got test coverage that insures you won't break any existing functionality.

Answer 6

My opinion - One should go back and fix "working" work when someone is paying for it to be fixed.

Of course, I'm an unrepentant capitalist consultant, and most of my work is basically a customer shows up with a request for XYZ application and I build it for them.

That said, for my play project (an open-sourced .NET CBR reader) I'm always happy to immediately implement new things into it--but again, that's what it's for.

Answer 7

I guess that depends if it's code for personal projects or work. If it's work, obviously it's up to your boss in the end. If you can convince them that this needs to be done and they're willing to give you the time away from other projects to do it, then do it.

Answer 8

I never feel that rewriting code you wrote in the long past is worth the trouble unless it is broken, because it is often broken in such a fundamental way that you will start from scratch. Focus your newly acquired Jedi skills rather on new challenges.

That being said, in case you refactor, make sure you have those test cases ready to help you catch those regressions that you will introduce.

Answer 9

To address part of your question:

Where I work, it would be wrong to go edit things that are not broken. In a production environment, where people are using your code all day every day, you would be reprimanded for "tweaking" code that has not already been reported as broken. On the (preferably) slim chance that you make a typo or accidentally change some functionality, someone else is going to suffer while they troubleshoot. In other words, development is going to cause problems for support. Also, paying someone to make changes to something that is not broken is a practice that my employer would tend to avoid.

Answer 10

If we're talking about production code, I'd say make the changes if:

• You can spare the time without jeopardizing other projects / release schedules
• The improvements will make the application more efficient / faster
• If the performance improvement is not substantial from the standpoint of the typical user, roll out these changes as part of a version with new features (don't do a refactoring-only release, unless it is largely transparent to users)
• You have your code under source control. "If it ain't broke, don't fix it" only applies when you can't at a moment's notice return to the unbroken state. Source control is critical to changes of this kind.
• You have unit tests around most of the components that will be reworked. You don't want to screw anything up for users just because of a refactoring attempt; the best way to avoid this is to have tests in place that verify the before and after behaviour as being identical.

Answer 11

"New/better" is no substitute for "well-tested in the field". If something in my code has been working reliably for years, I won't touch it.

Think of your code as being like horseshoe crabs - Nature has invented "better" ways of doing things since they first showed up, but they're still around and going strong.

Answer 12

I think about this all of the time and it is not an easy question to answer. Basically, if the code I want to rewrite is likely to never be used again, I dont do it. Unless its something I wrote outside of work. Then, if it was a cool enough program I will most likely rewrite it. However, if it is work related I probably would not do it unless, it can really make the code a lot stronger.

But I wouldn't unless you know for sure that it is an improvement.

Answer 13

Refactoring existing [production] code which is otherwise functional and generally satisfying to its end-users (and to a lesser degree to its maintainers) is, generally, a bad idea. Here is why

• Often it doesn't make economic sense.
• It introduces the risk (the certainty!) of introducing new bugs, which will then require fixing and which will be disrupting to the end-users
• Often our ideas about "doing things better" are merely tied to a fad or misconception: keep the new ideas for the new code ;-)

At a more philosophical level there are two points to consider:

• The distinction between engineering and elegant/perfect design
  Engineering allows us to deal with imperfections in the design!
  So while it is useful and often beneficial for strive for the most elegant way of designing things, and use tools which allow producing practical and workable applications even though their individual parts may be less than optimal.

• the relative advantages and drawbacks of creation versus evolution
  Although the analogy with biological evolution breaks down because software evolution is more directed (i.e. re-introduces bits of creationism during evolution), we should beware of that continuous evolution of a software product is likely to increase the overall complexity of that system.

Answer 14

IMO, this depends a bit on a few factors:

1. Current project or not - Would this be going back to a previous project to make the change and opening a can of worms to do this? Where I work, there is our current project and while I may learn this and that, I'm not about to go into older projects and create new problems in trying to apply something that I thought would be simple. Another thought here would be to take what is in SourceSafe and move it to Subversion, which may be useful to have just one software for version control but would likely not universally seen as a wise investment of time as most of the developers here are used to using both.

2. Age of code - Is this code that I worked on recently or would I be spending a great deal of time understanding what I did way back when? While this is similar to the above, my current work project has been going on since June of 2008 so there are things I worked on a year or more ago that really may not be as worthwhile to go back and change.

3. Scale of change - Is this going to take weeks or just a few hours? This is also something to consider as little changes can sometimes lead to hours of work fixing this and that which become new bugs due to side effects in the change.

Those are a few things that would guide me as well as trying to remember that just because something may seem better, it isn't necessarily something to use everywhere. For example, trying to use a drill on a nail isn't a great idea but if you just learned how to use a drill and want to use it everywhere, then there may be problems where other tools like a hammer or wrench may be much more useful, so don't forget that there is the right tool for the job that can also be worthwhile.

Answer 15

In general, no, "if ain't broken don't fix it". However, if you made substantial hacks/workarounds to get something working and you know that this will cause problems later then it usually pays to refactor it.

Each decision is based on effort/risk vs payoff. If you know the scope of the change well and can estimate the fixing cost accurately it may pay off. However, if it's a wide ranging change, this usually leads to version 2 syndrome where you start rewriting everything and there lies the problem...

Answer 16

Despite Time/Budget/Quality Project Triangle, you shouldn't consider refactoring your code unless:

• The code is buggy / so-so working with the rest of app.
• There will be a new feature update that will use your experienced code ;)
• its a non enterprise project ( your mothers web blog written about 10 years ago using PHP and text files ;) ) or an open source project - you can get satisfaction and experience while refactoring.
• When your co-workers are pissed when they using your code.

You'll be a better programmer when you write more.