Oh, this hits close to home. Warning: Venting through wall of text follows.
My first professional programming experience was in the early 2000's fixing and maintaining a Perl code from the mid-1990's. I wasn't a contractor, but the original author was no longer available, and there was little-to-no comprehensive knowledge about the code base in the company. We had plenty of people that could dive in and learn and fix, but as often as not, the answer to "how does that go about doing that" was "I guess we'll find out".
Later, I went to work for a local IT consultancy, and occasionally did short term and long term contractual software engineering. The majority of the horror stories I have are from this period.
I worked on a Payday loan company's code base where the original author was one of the owners, but was largely absent by the time I was working on it, due to personality and substance abuse issues. Once when making a change to the portion of the system that generated the ACH deposit file that was submitted to deliver money to customers, I noticed a commented out line that added another row, all statically defined, to put a couple thousand in a specific account. The comment above it said something to the effect "XXX's vacation allowance", where XXX was the absent owner and original author.
I worked on extending open source call center software which was essentially a bunch of multi-thousand line Perl scripts run through Aseterisk. Unfortunately, the original authors either didn't know about use strict, didn't know what scope was, and didn't know how to pass arguments to functions, or it was all an elaborate way to generate consulting feels for the original authors. Every function call was preceded by setting global variables which were then used within the function. If multiple SQL queries were needed, it was always "$stmtA = .." then "$stmtB = ". Prepared statements and variable binding? You wish. Generally, about 20%-80% of the code of any particular script (of well over 30) was generally shared with 2-5 other scripts, with no abstraction to a shared module, making the possiblity of changing one spot but not others likely, and corruption of the SQL data controlling the state of the system likely. The SQL schema itself wasn't exactly a dream to work with either...
I worked on fixing an implementation of a financial services company's rating algorithm implemented purely in SQL. The original IT employee responsible had disappeared one Thursday, and I'm not sure if they ever figured out what happened to him. The general vibe I got from them was that he probably took off on a vacation and decided not to come back. The code wasn't horrible, but making fixes to page-length dense SQL statements based on vague directions that certain stocks don't quite match the output for the Excel formula the owner developed years before is nerve wracking, when the entire business is generating reports based off this formula and selling access, and they need changes to this formula yesterday, and have little in the way of formal verification of the output.
Finally, a story to somewhat temper the WTF stories above. When returning a decade later to the company of first job, I ended up doing most the heavy work on the ancient mid-1990's code that ran their custom CRM, having had experience with it when working on it in the early 2000's. This software was always baffling, because the original author, who while to my understanding was somewhat of a Perl novice when he began the project had made the extremely odd decision to forego functions for a large set of twenty or so chained GOTO statements for each "route" (action param, in this case), instead of a simple cascaded if statement to function calls for each route, which is not only easier but much more likely to be the first choice for a novice (IMO). I finally determined the reason for this when making a larger structural change to fix this. The code was meant to (and did) run through mod_perl. Mod_perl speeds up Perl by taking the script, and essentially wrapping the content in a function, and persisting it. Unfortunately, if you have a bunch of functions defined in another function and they happen to use even just a couple "global" variables (not so global now, since they are defined in the outer function), you get closures, and data persisting between HTTP requests that should not. Using GOTO statements was a somewhat crazy, but definitely functional, way around this. Sometimes the WTF you've just encountered has justification, and it takes a deep dive to understand the code enough to know why.
Oh, that feels better. It's nice to vent every once in a while.
> Sometimes the WTF you've just encountered has justification, and it takes a deep dive to understand the code enough to know why.
God forbid some documentation. At a previous employer I was consistently baffled at how nearly all information about the mission critical application (and the business) was distributed through random verbal conversation, with the remainder coming from those deep dives into the code (at least until I could no longer hold my breath). There was literally zero documentation for an application with 1 million lines in the source tree and another million in SQL stored procedures (!!!). The size of the project alone was shocking considering it was a fairly standard line of business app, albeit with inventory, HR and customer interaction all rolled into one, but the experience was just about as bad as it gets for development and organizational practices.
The GOTO programmer probably learned to code only from reading BASIC programs. I didn't know about functions until I was formally taught in my high school programming class.
My first professional programming experience was in the early 2000's fixing and maintaining a Perl code from the mid-1990's. I wasn't a contractor, but the original author was no longer available, and there was little-to-no comprehensive knowledge about the code base in the company. We had plenty of people that could dive in and learn and fix, but as often as not, the answer to "how does that go about doing that" was "I guess we'll find out".
Later, I went to work for a local IT consultancy, and occasionally did short term and long term contractual software engineering. The majority of the horror stories I have are from this period.
I worked on a Payday loan company's code base where the original author was one of the owners, but was largely absent by the time I was working on it, due to personality and substance abuse issues. Once when making a change to the portion of the system that generated the ACH deposit file that was submitted to deliver money to customers, I noticed a commented out line that added another row, all statically defined, to put a couple thousand in a specific account. The comment above it said something to the effect "XXX's vacation allowance", where XXX was the absent owner and original author.
I worked on extending open source call center software which was essentially a bunch of multi-thousand line Perl scripts run through Aseterisk. Unfortunately, the original authors either didn't know about use strict, didn't know what scope was, and didn't know how to pass arguments to functions, or it was all an elaborate way to generate consulting feels for the original authors. Every function call was preceded by setting global variables which were then used within the function. If multiple SQL queries were needed, it was always "$stmtA = .." then "$stmtB = ". Prepared statements and variable binding? You wish. Generally, about 20%-80% of the code of any particular script (of well over 30) was generally shared with 2-5 other scripts, with no abstraction to a shared module, making the possiblity of changing one spot but not others likely, and corruption of the SQL data controlling the state of the system likely. The SQL schema itself wasn't exactly a dream to work with either...
I worked on fixing an implementation of a financial services company's rating algorithm implemented purely in SQL. The original IT employee responsible had disappeared one Thursday, and I'm not sure if they ever figured out what happened to him. The general vibe I got from them was that he probably took off on a vacation and decided not to come back. The code wasn't horrible, but making fixes to page-length dense SQL statements based on vague directions that certain stocks don't quite match the output for the Excel formula the owner developed years before is nerve wracking, when the entire business is generating reports based off this formula and selling access, and they need changes to this formula yesterday, and have little in the way of formal verification of the output.
Finally, a story to somewhat temper the WTF stories above. When returning a decade later to the company of first job, I ended up doing most the heavy work on the ancient mid-1990's code that ran their custom CRM, having had experience with it when working on it in the early 2000's. This software was always baffling, because the original author, who while to my understanding was somewhat of a Perl novice when he began the project had made the extremely odd decision to forego functions for a large set of twenty or so chained GOTO statements for each "route" (action param, in this case), instead of a simple cascaded if statement to function calls for each route, which is not only easier but much more likely to be the first choice for a novice (IMO). I finally determined the reason for this when making a larger structural change to fix this. The code was meant to (and did) run through mod_perl. Mod_perl speeds up Perl by taking the script, and essentially wrapping the content in a function, and persisting it. Unfortunately, if you have a bunch of functions defined in another function and they happen to use even just a couple "global" variables (not so global now, since they are defined in the outer function), you get closures, and data persisting between HTTP requests that should not. Using GOTO statements was a somewhat crazy, but definitely functional, way around this. Sometimes the WTF you've just encountered has justification, and it takes a deep dive to understand the code enough to know why.
Oh, that feels better. It's nice to vent every once in a while.