It’s so sad, but this is typically the way corporations work. developingchris, above, got it right. It’s the standard MO of IT programmers. I have tried to change this, but when new functionality requests come in, most of the team does the same as they always do: just keep cobbling on to the existing foundation. Depressing though it seems, this is unlikely to change in most shops.
I agree with earlier commenters that your real problem might be that you need to write (more) tests for that (specific part of the) code. If you have a fast-running test suite it should be pretty easy to see that on ctrl+s you just broke your tests, hit ctrl+z a few times and try again. Or do you have plenty tests and is the problem that you cannot get your test suite to pass in any other way than the current patch code? If so, perhaps your current test suite tests too specifically, that is, it tests only that your code is written as it is now, rather than testing how the code should behave?
@Dylan
"If you are writing code experimentally, you may want to rip up the function you wrote last week when you think of a better algorithm. That’s fine. You may want to refactor a class to make it easier to use. That’s fine, too. But throwing away the whole program is a dangerous folly, and if Netscape actually had some adult supervision with software industry experience, they might not have shot themselves in the foot so badly."
From your linked article. Joel’s article on “don’t rewrite the netscape browser” isn’t really a counterpoint.
I had a refactoring win recently. There was one section of code that needed to be modified for a defect fix, but I could see that the whole method, a tangle of nested ‘if’ blocks, needed to be reorganized. Since there were no unit tests for the code, I created a test harness that covered the section 100% on existing behavior. Now, with a test harness safety net, I was able to fix the defect and simply the logic in the method, all while retaining the exact behavior that I started with.
My solution: hire a very skilled coder (temporarily), looking to it with a completely fresh eye. The fresh look combined with the skills should generally come up with a creative, longer lasting solution to the problem at hand.
More importantly: detect early on in the process that you are only patching the patchy dog. Only then it becomes sensible to pay an external coder to solve your patchy patch-dog code.
these random analogies are becoming quite ridiculous, no?
I’m wondering what you think of the programming antihero at the end of the article. It sounds like a bit of too-much-cleverness.
I’m wondering what you think of the programming antihero at the end of the article. It sounds like a bit of too-much-cleverness.
Ah patche… i’ve been doing that since i started working in my actual job, why?, is not like I am not able to rewrite the code but the time they gave me to finish the correction is too short, so… patch… give me the power to complete my work… and it (sadly) works!
Yep, that’s a Miniature Schnauzer without the cropped ears–like mine! Great dogs. Now, what was this post about…?
There’s a grammatical mistake towards the end “shamed me INTO TO attacking a section” should be “shamed me INTO attacking a section.” Time for another patch!
Something like this happened to me recently as well. I had a particular piece of code, where my boss said “the last guy told me to tell you it’s tricky to work with.” /facepalm. 3 weeks of consistent bug reports day by day with this piece of code. It boggled my mind how convoluted this thing was. After those 3 weeks, I decided to ‘screw it’ and rewrite the thing from scratch. Took a couple of days to iron out the details but it’s been going fine for a few months now.
Turns out that this piece of code had been patched and patched (ad infinitum) for about a year.
Have your test coverage, and you will feel much more safer doing bigger changes. Now, of course, the question is wider that just that, it’s more about human psychology, and so far the answer is - patch until it is totally unbearable, and rewrite then. Long and painful way to go. Does anyone know better?
I am usually not afraid to rewrite/refactor my own code. Diving into someone else’s mess - that I think twice about (or however many times it takes to convince myself to not do it).
The bigger, and older, someone else’s mess is, the less inclined I am to fix it. Several gigs ago I worked on legacy code that was so poorly written and architected, that nobody on the team wanted to touch it any more than was necessary to patch it or add to it. Never mind the methods with 5000 lines of code, and/or 25 inner methods - the architecture (if you could call it that) just plain sucked. I called it the upside down pyramid architecture because if you didn’t balance your patches/additions just right it would fall over and crash every time. Hell it would crash if you looked at it cross-eyed.
Everybody (except management/marketing/sales) wanted to start from scratch, and we started to several times, in small modules, but even that is hard when you are working on the holy cash cow for the company and the legacy code is not modular so you can’t replace modules.
Of course, the hardest part of refactoring/re-writing anything is convincing the management to let you write something that to them is already finished (so what if it has a few bugs?).
My experience is that patch vs rewrite is an engineering tradeoff question, a risk management question.
Or, as everyone loves to hear, “It depends”.
I agree completely with the original Gamasutra post, but I think the Coding Horror version is missing the point. In the Gamasutra piece, fixing the bug is the key point:
“That experience soured me against “the patch.” Now I always try to dig right down to the root cause of a bug, even if a simple, and seemingly safe, patch is available.”
By contrast the Coding Horror version talks about a fundamental rewrite:
“In those circumstances, it’s easy to mentally justify “just this small change, just this once” rather than the fundamental rewrite you really need.”
In my experience, fixing a bug by identifying its root cause is usually a better solution than rewriting from scratch. In fact, I often find that when the cause of a bug is really understood it can often be fixed with minimum code changes. Complete rewrites are sometimes an indication that the developer doesn’t know what the problem is, and may just end up back at square one.
I’m not saying this is the case with the Stack Overflow code, there isn’t enough information in this article to tell, but this post does seem to suggest that the only problem is that the code had become crufty. By all means clean up crufty code, but don’t confuse that with bug fixing.
Nice point !
Not only in development or maintenance this scenario happens in many aspects and areas of out lives.
You must read Hacker News…