![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Stuff and Nonsense [Computer geekery]
Oct. 12th, 2006 10:42 pmGood week. I've been working mostly on fixing map code that was almost-good-enough-for-release-but-not-quite. I'm discovering that I kind of like being the person who comes in and patches things like that up. Debugging my own code is a special kind of hell (I wrote it thinking it was of course brilliant at the time, so later when it clearly turns out to be, in fact, an awful writhing mass of Doom Spaghetti(TM) it can be tricky to figure out why it's broken when it seemed so smart to do it that way...) but when I'm looking at someone else's with a fresh eye and no pre-conceived illusions as to its coherence it becomes much easier. Usually.
I've managed to get the current part (which was almost functional enough, thanks to hacks piled on top of hacks piled on top of conditional logic such as "if the width of the user's resolution is greater than 1024 pixels, use 1280x1024 for the map dimensions. Otherwise, use 800x600.") mostly working--there's still one little glitch that I know of, but it's obscure enough that it is unlikely to cause problems, and it should be completely gone in the subsequent release. On this release I used the very messy but ever popular algorithm, "Rip out broken chunk of code by either deleting it or putting it in a massive comment block. Replace it with code that is almost as bad because it's got to work with the other bad code that hasn't yet been ripped out, but which works better than what was there before. Repeat until bare minimum functionality is reached overall." This is usually marginally faster (depending on how widespread the bugs are and how many layers deep) than ripping everything out and starting more or less from scratch, and therefore tends to be the method of choice when up against a deadline. However, it leaves the "repaired" code very susceptible to new bugs, since the underlying problems (poor variable naming, indentation, code arrangement, etc.) from which the bugs arise has not really been addressed; I've treated the symptoms, but I haven't fully cured the problem yet.
So hopefully as soon as this release goes out I'll be taking the time to do the rip-it-out-and-start-from-something-like-scratch method.
I think another reason that I like working with existing code like this is because it gives me a framework within which to maneuver. I have some sort of scope, some idea of where the boundaries are, that I don't always have when someone tells me to implement a new bit of functionality. I have programming agoraphobia!!! ;-) Though at my current job that has been less of an issue than in past places--I'm getting much more specific requirements, and so I usually have some concrete way of telling when I'm done besides "it's not broken anymore" ^_^
I've managed to get the current part (which was almost functional enough, thanks to hacks piled on top of hacks piled on top of conditional logic such as "if the width of the user's resolution is greater than 1024 pixels, use 1280x1024 for the map dimensions. Otherwise, use 800x600.") mostly working--there's still one little glitch that I know of, but it's obscure enough that it is unlikely to cause problems, and it should be completely gone in the subsequent release. On this release I used the very messy but ever popular algorithm, "Rip out broken chunk of code by either deleting it or putting it in a massive comment block. Replace it with code that is almost as bad because it's got to work with the other bad code that hasn't yet been ripped out, but which works better than what was there before. Repeat until bare minimum functionality is reached overall." This is usually marginally faster (depending on how widespread the bugs are and how many layers deep) than ripping everything out and starting more or less from scratch, and therefore tends to be the method of choice when up against a deadline. However, it leaves the "repaired" code very susceptible to new bugs, since the underlying problems (poor variable naming, indentation, code arrangement, etc.) from which the bugs arise has not really been addressed; I've treated the symptoms, but I haven't fully cured the problem yet.
So hopefully as soon as this release goes out I'll be taking the time to do the rip-it-out-and-start-from-something-like-scratch method.
I think another reason that I like working with existing code like this is because it gives me a framework within which to maneuver. I have some sort of scope, some idea of where the boundaries are, that I don't always have when someone tells me to implement a new bit of functionality. I have programming agoraphobia!!! ;-) Though at my current job that has been less of an issue than in past places--I'm getting much more specific requirements, and so I usually have some concrete way of telling when I'm done besides "it's not broken anymore" ^_^
