I don’t fear meeting my Dog as much as taking over someone else’s Dog.
Mine might just growl at me, but the other Dog most properly will bite me especially if the owner has already left the company.
Also, if you a fellow programmer tells you a complex piece of code (preferably part of the core) is working, don’t touch or change it. There is a good chance you’ll find a Dog in it.
And I am talking out of experience.
We’ve been finding that “it’s working code; what’ll happen if we change it is” means we have insufficient regression testing. Rewrite the darn thing and throw your automated test suite at it. In the morning, you’ll know your change was good!
This is the type of situation that test driven design/refactoring are supposed to fix. If (big if) you have tests for the interfaces, rewriting the implementation is risk-free, because you will know whether you caught everything.
As counterpoint, here’s your mate Joel on why the worst thing you can ever do is ‘do over.’
The “falling off the world” problem is easily fixed by making “Damp” fatter.
Yeah, nice dog BTW 
This whole problem gets alot worse when you have a boss that sees full rewrites as a big waste of time and insists you just make small changes to get things working. Over time the system becomes worse and worse until it is totally unmanageable.
My way out has been to do refactors on the side while doing my main work so when the time comes I can merge in my clean rewrite without needing to tell my boss I’ll need a few days to redo things.
What you describe is the way how my company wants me to work… but I refuse to work that way. If you write a piece of code and you cannot get it the right first time, that is okay. Rarely you can really get it the right first time. There is a problem? Fix it. The fix doesn’t always work, fix the fix. The fixed fix is too aggressive? Make some exceptional rules. However, if you then see it’s still not working right and every new fix just gets me feedback that now this or that is broken - throw this piece of crap away.
Maybe you cannot ever get it perfectly right because the code was the utterly wrong approach from the very beginning. Rewrite from scratch has solved so many issues already. My supervisors always get mad at me when I do that… but once rewritten, the code works, no more patches, everyone’s happy. So they calm down and maybe 6 months later they say “Remember how mad we have been that you rewrote all this code without our permission? I think it was the right thing to do”. Of course it was!
It’s just unbelievable how masochistic some programmers can be and keep on patching and patching and patching. My threshold for pain is somewhat lower regarding this aspect. No rewrite has ever caused worse code than we already had - either it got better… it I rewrote it three months later again 
Count me in! I’ve been patching some code for a week now. Opened the reader this morning and found this post. 
This is what I call stochastic debugging. You know it is fundamentally broken, but you hope you’re going to find all the places where a user can tell. Even if you’ve found them all, you’ll never know you’re done; there could be one more. And it is still fundamentally broken.
So what was the “extra-patchy Stack Overflow” you attacked? How long did the rewrite take? Was it successful? Have you had to add any new patches? How does the new code compare to the old? Where there any specific reasons you’d had so many problems in the first place?
I look forward to reading part 2.
It seems a little Schnauzer, like my sister’s.
Yay! Good post. I’m actually doing that right now with the website I’m working on by rebuilding the basic framework from the ground up. (It should still work with the actual pages in much the same way, so it’s not a terribly gruesome task.) Totally in touch with the emotion, some of the code I’m referencing for the build would make a coder blush, and I think I even wrote some of it… -_-
It’s always amazing to me how bad some of my own code looks 2 years after I wrote it. But then again, 2 years ago I barely knew the language.
PS-- Captcha: “hall brains”
Been there, done that, decided an Electrical engineer has no business pretending to be a software engineer in the first place.
Joel’s post made a lot of sense when he wrote it in 2000, but that Netscape rewrite gave us the Gecko rendering engine and ultimately Firefox.
Maybe it wasn’t such a bad idea after all…
The quoted example is a case of bad design. The collision system should’ve been designed to first of all share vertices among triangles and second to map out accessible space, not inaccessible solid.
Replace PS1 with something that works.
captcha: $3.4-billion mordants
I shall ask the stakeholders what they want to do with the rascal.
I couldn’t agree more with you Jeff. ESPECIALLY in the games industry we rely far more heavily on large QA departments than we do on unit testing or any other proactive solution.
The common game development process is extremely iterative with your design being developed with your engine. Developing proactive testing solutions for your code is often not worth it if the code will change next month. It also boils down to the fact that QA departments can be shared amongst several studios such that there is no down-time for them and they are getting paid hourly wages that are close to minimal wage (or less if outsourced to another country). In many cases, it’s just simply cheaper to have a large QA department bang out for weeks on end the most obvious and obtrusive bugs and let some junior level programmer patch it while your mid level and senior level guys continue to grind away at implementing new features or change key design elements based on designer needs. This segways into some fundamental flaws in the development strategy of games but I’ll spare you that rant.
I hope you took the time to wrap that section of code with unit tests before you went in and refactored. Double bonus – you make sure it’s still working as expected and next time you won’t need to avoid making changes because you’re afraid you’ll break it.
pleaso jeep