3 ms·
I did - please bear witness while I work through my trauma. Variable names were actively obfuscatory, and their declarations were always many hundreds of lines
by rdiddly 8y ago
I did - please bear witness while I work through my trauma. Variable names were actively obfuscatory, and their declarations were always many hundreds of lines distant from their use. And many weren't even used at all. Or some were assigned values that never got read or used for any purpose. In a language that generously provides many useful data types, booleans were being converted to strings so he could check whether it was equal to "true" (like t-r-u-e, the literal string). No generics: instead, arrays everywhere, even in cases where the number of items wasn't known ahead of time. (Just size it to 10,000 x 500 and hope you don't overrun. It eventually always did. So he would bump it up to 20,000 x 600 or something.) No modularity... everything just one big function. And if you need to do the same thing somewhere else, just copy the code over there. Oh but make subtle changes to it so that the two copy-pastas diverge from each other in subtle ways that could've easily been parametrized. Copy-pasta marinara over here, copy-pasta pesto over there. I could go on (and on), but in short, it sucked ass. I concur with others here that understanding the code (since it sucked ass anyway) ended up being something of a lower priority than understanding the business processes.
That was the key actually. At first I diligently tried to understand the code, refactor, rename, move things around... but at some point I crossed a bridge where I suddenly understood, this code is not an asset to be protected and cared for; it's a liability that sucks my time into it and creates not just low, but negative, productivity. And if I don't kill it now, it may suck other victims in. By that time I understood the business processes better and had better implementation ideas anyway, so I began "deleting with extreme prejudice" and rewriting. Even so, I still had to read and understand the code I was deleting or replacing, and was constantly thinking like this: https://www.youtube.com/watch?v=vbr9akNELdc https://www.youtube.com/watch?v=vbr9akNELdc (Yep that's Airplane! and you probably won't recognize the actor who 28 years later would play hitman/bodyguard Mike Ehrmantraut on Breaking Bad.)
Eventually I re-did the important parts and let the rest fall by the wayside. I didn't attempt to duplicate all the functionality embodied in that mess. It took 2 years but I remember the day I finally deleted the last piece of shitcode. Management was behind me all the way, because they were aware of some of the issues with my predecessor, plus over time they've become content for some reason to kind of just take my advice about this and other things almost implicitly. So I was lucky in that way; I was free to tackle it how I saw fit. They didn't really have much choice anwyay though, for the kind of money I was making at the time! (not great)
- naikrovek 8y agoCode that can't be quickly replaced is a liability, in my mind. Your example is an extreme case, and I think that even in non-extreme cases, code that has inertia is bad. The inertia is just not AS bad as the inertia in your story. If you can't, (as an example,) wrap your mind around a codebase that implements a bit of business logic, in a day, that code is too complex. It should be replaced with something that can be understood quickly, and changed quickly, when the person who maintains it today, dies, retires, or goes on vacation. (In the above, substitute "day" for whatever period is suitable for your situation, and "person" for whatever employee-unit is suitable for your situation; "lead dev", "team", whatever.) Software has more inertia than hardware, and that is INSANE. There is software at my employer that is OLDER THAN THE FUCKING X86 ARCHITECTURE, and has gone untouched for much of that time. "If it works, why touch it?" A business needs to understand what is running (for legal and other reasons) and needs to be able to fix it, change it, or replace it very quickly, because if it is implementing a business process, it is important for business, and if it is important for business, then it needs to be able to adapt as the business adapts. Some things change very little, true; that doesn't mean everyone who worked on it should be allowed to retire, then rehired as contractors 20 years later when the mainframe hardware finally goes out of support.