Have You Met Your Dog, Patches?

The Gamasutra article Dirty Coding Tricks is a fantastic read. One part of it in particular rang true for me.


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/08/have-you-met-your-dog-patches.html

My nieghbor had a gopher problem. Filling in each hole that appeared never really fixed his yard. Based on his experience I’ve decided to remodel my kitchen.

‘Total rewrite’ is usually based on the logic:

  1. I have a bug I cannot fix. This is making me look bad.

  2. powerpoint slides, design documents and prototypes do not have such bugs.

  3. So if I am doing them instead of debugging, I will not look bad.

Projects generally only fail for technical reasons at the point of delivery. So if delivery is pushed off, technical failure becomes impossible. Chances are, some random non-technical issue will intervene to scrap the project before delivery of the new version. Or else you’ll be in a different job, with +3 years experience of whatever cutting-edge technology was picked for the rewrite.

That’s completely different from taking the worst 5% of the code-base out and shooting it like a mangy dog. People who do complete rewrites do so because they don’t know which dog to shoot.

Had the same problem with some awful interface code that imported csv files into Siebel via escript. Every change we made to the system even if its had nothing to do with the area it was importing to resulted in 3 days of retweaking this godawful code.
It could have been rewritten in about a month (it was a stinker in terms of structure, and using csv is fraught at the best of times when you have users with excel in different setups all over the place), but it was “90%” there to begin with ( I REALLY REALLY should have said no, redo it before we put it live, but was sort of persuaded to go with it). I think the real problem was the HPC said initially it wa 3 days work - probably the biggest lie I’ve ever heard in a meeting.
anyway 6 months later I’m still there fixing this utter utter hell of an interface without being able to rebuild it (even then it would have only been a “bit” better, the entire design was flaky because it was from a previous system which handled errors by ignoring them.

I’m with Craig - give yourself the safety net of a set of unit-tests which you develop to confirm the current operation and fail on the areas you know need to be reworked. Then change-away :slight_smile:

Thought I’d better add the pressure was always on to get it working and running again until the next bug. It was always a case of ‘next time’ to fix the glaring problems (one of which was it it the 16 k code limit before it was working - there was some real hacking to get to 90% therebefore we started.
This was for 1 country - we then were forced to do the same for another 10 in short order so a copy was done with some more hacks and stupidity we got that sort of working.
Eventually we moved everything over to something that did work , but it was 18 months of hell as far as I’m concerned.
thankfully we have a bit more clout that we can push back and say ‘no, this is stupid’ a bit more but the point i’m essentially making is that despite everything its not always your choice in how these things end up.

Corrigendum ad infinitum

Now this is something I can agree with :slight_smile:

Funny thing you write this now, 'cos I’m busy doing just that - patching my heavily patched code and avoiding a rewrite! And look, I finally get to make the first comment on a proper blog post. Yay. Time to go now, that patch isn’t going to write itself. :wink:

Don’t let yourself get attached to anything you are not willing to walk out on in 30 seconds flat if you feel the heat around the corner - Heat (1995)

(http://javadots.blogspot.com/2009/08/software-design-comes-to-hollywood.html)

Are you saying Patches should be put down? Awww, poor Patches

Reminds me of the old adage: Where do you most fear the bug is? That’s probably where it is.

Counterexample: Evolution. Nothing but patches. Ever.

Now that’s one cute dog.

reminds me of this Eric Lippert’s post:
http://blogs.msdn.com/ericlippert/archive/2009/06/01/bug-psychology.aspx

cute dog

I found myself continuously fixing the same code over and over again simply because I am not smart/skilled enough to rewrite it in a better way. A way that wouldn’t require any fixes at all. But doesn’t this seem as an impossible chimera, at least in the common case? I think that one should have really extensive experience as a coder so that he can afford to throw away a half-working code and start over again. The chances, at least for the average programmer, are that he would produce the same half-working code but with different look.

I think you chose a picture that is too cute to represent this problem.
I had a hard time feeling the analogy, given the cuteness of the dog.

But that is the problem, its tempting to just ball of mud it up. When I have been a consultant, it has been my main task to convince the lifers that this is their MO. And that while it works in the short term, they are lifers and they’ll be the ones dealing with it in a year when they have no clue why it got so bad.

Good post, concise.

Ironic that you’ve regularly poo-pooed the value of unit testing. One of the most valuable aspects of testing is giving you more peace of mind that you can change code without breaking things.

Maybe if you had tests, you wouldn’t be so hesitant to fix your code.

I deeply feel this pain. It’s what caused me to write this yesterday:

Will the defendant please rise. After having your code reviewed by a jury of your predecessors, you have been found guilty. I sentence you to life in prison with no possibility of parole. May God have mercy on your soul.