Accidental Technologist

Musings about Entrepreneurship, Technology and Software Development

  • Home
  • About
  • Still River Software
  • Privacy Policy

Powered by Genesis

You are here: Home / Programming / When Refactoring Code is a Waste of Time

When Refactoring Code is a Waste of Time

September 10, 2008 by Rob Bazinet

Tweet

WasteButton We hear this all the time, a developer going in and finding some code someone else wrote and they start hacking at it to make it look more like their coding style than the original and they label it "refactored"

Sometimes we need to look at someone else’s code or even our own to resolve a bug and at times it is necessary or efficient to rewrite part of the code to better assist in solving the problem.  This brings client value, a bug has been fixed.

We may have code we wrote a long time ago and the code does not reflect our current style and attention to detail.  Changing this code so we may better support it later adds long-term value to the client, the code was updated by the author and is better maintainable and reflects their up-to-date knowledge an brings value to the client.

I have worked with some arrogant programmers before who think they know it all and can turn code they deem as unacceptable into acceptable code (aka their code), you know who you are.   I have been programming a long time and I certainly don’t know it all, far from it.  I am always willing to learn better ways to do things but I don’t have the arrogance to run into a fellow developers code and change it because I don’t like the looks of it.

This is one thing really annoys me and makes it really hard to justify to the client who often times never finds out but is billed for anyway.  This as a huge waste of time, money and introduces potential bugs.  If the code works and is not a bottleneck in the system, just leave it alone.

Please don’t do this….you know who you are.  I would like to hear from all the refactoring fan-boys out there that insist on this behavior and why they feel the need.

Technorati Tags: Refactoring

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Related

Filed Under: Programming

Care about your privacy? I do and use Fathom Analytics on this site.

Fathom Analytics

Comments

  1. Michael Eaton says

    September 10, 2008 at 10:35 am

    I almost fell into this trap recently. I inherited a project and when I saw what a steaming pile it was, I started hacking it to be the way *I* would have done it. After hitting a couple classes, I realized how stupid it was and bailed.
    I only refactor when I have a reason – if I’m in a particular section of code working on something, it’s a no-brainer. If I’m passing through, but aren’t changing anything else, I don’t.

  2. Michael Eaton says

    September 10, 2008 at 10:35 am

    I almost fell into this trap recently. I inherited a project and when I saw what a steaming pile it was, I started hacking it to be the way *I* would have done it. After hitting a couple classes, I realized how stupid it was and bailed.

    I only refactor when I have a reason – if I’m in a particular section of code working on something, it’s a no-brainer. If I’m passing through, but aren’t changing anything else, I don’t.

  3. The Admin says

    September 10, 2008 at 10:39 am

    @Michael My point exactly! It is hard to resist sometimes but we are better off for it if the code is just working fine. I have too often just seen the coder who thinks he is the "master" and just go nuts refactoring and cause problems.

  4. The Admin says

    September 10, 2008 at 10:39 am

    @Michael My point exactly! It is hard to resist sometimes but we are better off for it if the code is just working fine. I have too often just seen the coder who thinks he is the "master" and just go nuts refactoring and cause problems.

  5. Dan Bernier says

    September 10, 2008 at 3:51 pm

    I once wanted to do this very badly. I’d inherited code w/ a TON of complexity, and a lot of it seemed needless. I wanted to rip through the code with a machete, and tear about half of it out, but I held back. After living with it for a week or two, I talked it out w/ a senior developer (I was pretty green), and he said sure, clean it up. The resulting code was -much- better. The original coder had been reading GoF, and made himself a gratuitous Pattern salad. With all the "extra" out of the way, you could see what the code was supposed to do.
    OTOH, I’m guilty of making fastidious code-hygiene fixes, and introducing bugs. It’s frustrating to take a much prettier bunch of code with a tricky bug, and revert it, because the original code at least works right, as far as you can tell.
    It’s a dull conclusion, but it comes down to judgment. Sometimes it’s really worth it, even if it takes a while.

  6. Dan Bernier says

    September 10, 2008 at 3:51 pm

    I once wanted to do this very badly. I’d inherited code w/ a TON of complexity, and a lot of it seemed needless. I wanted to rip through the code with a machete, and tear about half of it out, but I held back. After living with it for a week or two, I talked it out w/ a senior developer (I was pretty green), and he said sure, clean it up. The resulting code was -much- better. The original coder had been reading GoF, and made himself a gratuitous Pattern salad. With all the "extra" out of the way, you could see what the code was supposed to do.

    OTOH, I’m guilty of making fastidious code-hygiene fixes, and introducing bugs. It’s frustrating to take a much prettier bunch of code with a tricky bug, and revert it, because the original code at least works right, as far as you can tell.

    It’s a dull conclusion, but it comes down to judgment. Sometimes it’s really worth it, even if it takes a while.

  7. Michael Eaton says

    September 10, 2008 at 5:47 pm

    @Dan:
    "It’s a dull conclusion, but it comes down to judgment. Sometimes it’s really worth it, even if it takes a while."
    That’s true. In my case though, I bill my clients by the hour so sometimes I can’t jump in and refactor *everything* even if I want to.

  8. Michael Eaton says

    September 10, 2008 at 5:47 pm

    @Dan:

    "It’s a dull conclusion, but it comes down to judgment. Sometimes it’s really worth it, even if it takes a while."

    That’s true. In my case though, I bill my clients by the hour so sometimes I can’t jump in and refactor *everything* even if I want to.

  9. Rob Bazinet says

    September 10, 2008 at 10:57 pm

    @Dan it is a hard urge to resist but when the client is paying for it, it is hardly ever worth the effort. If the code works, be happy and move on.
    @Micheal – same here, I bill clients and touching code that already works doesn’t make them very happy.
    Great comments guys. I expected to be flamed actually.

  10. Rob Bazinet says

    September 10, 2008 at 10:57 pm

    @Dan it is a hard urge to resist but when the client is paying for it, it is hardly ever worth the effort. If the code works, be happy and move on.

    @Micheal – same here, I bill clients and touching code that already works doesn’t make them very happy.

    Great comments guys. I expected to be flamed actually.

  11. Ivan Porto Carrero says

    September 12, 2008 at 3:53 am

    I must admit that I’m guilty of refactoring but Idon’t go in and refactor the whole lot just the things I touch and when I see there are obvious problems with that code.
    If I inherit a project from somebody else I tend to leave the things that work alone but when I find lots of duplication and other smells I cannot resist and refactor that stuff out and then still only in the classes I actually touch. Is that the refactoring cowboy you’re talking about? The last thing I want to do is piss the people around me off 😉
    I don’t care much for programming style as I can follow most styles of development not that I like all of them but they pay me so I’ll follow the standards.

  12. Ivan Porto Carrero says

    September 12, 2008 at 3:53 am

    I must admit that I’m guilty of refactoring but Idon’t go in and refactor the whole lot just the things I touch and when I see there are obvious problems with that code.

    If I inherit a project from somebody else I tend to leave the things that work alone but when I find lots of duplication and other smells I cannot resist and refactor that stuff out and then still only in the classes I actually touch. Is that the refactoring cowboy you’re talking about? The last thing I want to do is piss the people around me off 😉

    I don’t care much for programming style as I can follow most styles of development not that I like all of them but they pay me so I’ll follow the standards.

Recent Posts

  • Social Media Times Are Changing
  • It has certainly been a long time…
  • How to Fix Rails Flash Rendering When Using Hotwire
  • Hotwire Fix for CORS Error when using Omniauth
  • Fix Installation of Ruby using rbenv on macOS Big Sur

Categories

Services I Love

HatchBox - Easy Rails Deploys Fathom Analytics
Follow @rbazinet

Rob Bazinet
@rbazinet

  • Great little utility https://t.co/6AgboJv6oI
    about 1 day ago
  • Funny watching the hate to show up in my time line for ChatGPT. People getting defensive about it.
    about 4 days ago
  • I just backed The SaaS Playbook, by Rob Walling on @Kickstarter https://t.co/1FpTWN9c9v
    about 5 days ago
  • This looks like an interesting project. I need to dig in a bit. https://t.co/gacEX9AmEn "Phlex — fast, object-orie… https://t.co/4AUL0Z0SBl
    about 5 days ago
  • I attempted to use ChatGPT today and asked a couple questions it couldn’t answer. I thought it was a magical black… https://t.co/uJGw0CgUAv
    about 5 days ago
  • RSS - Posts
  • RSS - Comments
Find me on Mastodon