Public sector contractor code is always the worst possible thing, but there was one that really took the cake.
This was C#. There was an abstract base class a lot of classes inherited from. The subclasses all called a protected method in the abstract base class.
As designs go, that's not bad, right? We can bicker over the value of inheritance, but there are worse things, right?
No! There aren't! Because the way that the protected method in the abstract base was implemented is it was using reflection to get the class name from this and comparing the reflected name of the calling subclass using a switch statement to find the right implementation based on hardcoded strings of subclass names!
I will die mad at that piece of code and how much more money that senior developer made than me.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
One time I worked for an agency, which I won't name but will refer to as The Bad Place. The management decided that instead of giving us, the web folks, a website to build, they'd get a contractor in to do it. It was in the days where the designers (who only worked on magazines) would send you a PSD and say, "make it web".
Anyway, it was a photo competition site, where people could submit photos and they'd appear in a gallery.
The only thing I can say about the code that's positive is that it resisted SQL injections. Because it didn't let people sign up. When the contractor left, without the management agreeing to spend any money on QA, it turned out that most of the buttons on the site were images that did nothing, because they'd never specified what they should do.
The killer code though... anyone could submit a picture of any size and it'd store it and serve it, uncached, no CDN, for anyone to see. So, a lot of spam, broken images and nudity.
People didn't complain about the spam though, because the gallery page was coded in PHP using:
mysql_connect()
a gratuitous SELECT *
a for() loop for pagination giving every 10 photos a wrapper div.
a bit of Javascript to hide or reveal pages
If you can imagine this, it means that every picture ever uploaded was rendered to the page all at once.
We got 80,000 uploaded photos over the first weekend.
varthisVariableDoesShitButICannotFindAMeaningfulName=0varthis_var_uses_snake_case_since_I_feel_like_it=1...// line 1001...// line 2001 and still goes on
^ Codebase of a simple plugin from my previous company 🤮
The code was created by a third party dev team five or six years before I joined the company.
The data structures were so unnecessarily complex that they were built with macros. The macros were probably generated from a spreadsheet (we found a spreadsheet that defined the macros) using something that is lost to time.
We're talking hundreds of macros. The macros have to use macros that run macros because the parameters for the macros are generated by macros. Some of the parameters in the macros are never used.
Why write C when you can just put everything in preprocessor instructions?
No unit tests. Practically no documentation.
This means that if we had wanted to change the structures at all we'd have to either reverse engineer the generator or go about it by hand, and then run two days worth of end to end tests to make sure we'd not broken anything.
Once was hired as a Senior engineer to refactor a codebase for an app that handles sensitive employee data. I'm a full-stack JavaScript engineer with some experience in other languages and found myself in a sea of Java engineers that had chosen GWT, which is deprecated, and the company can't figure out how to roll off GWT onto a modern stack. I quickly became Principal in one year because I successfully architected and prototyped a solution for the company's dynamic form layouts in a JavaScript environment. I built it to be server-side renderable, but those words "server-side renderable" were "bad words" at the company. No matter no hard I tried to sell it, no Java engineer could wrap their head around dynamic forms being server-side rendered, so the project remained client-side rendered and performed better than the prior implementation.
Engineers had tried and failed to integrate React with GWT because all they did was swap out the components and not the engine. JavaScript engineers that were being hired had no idea where to begin because GWT is not documented well and it's Java. At times it felt like engineers were sabotaging the migration by making painful ways to migrate off GWT that took a long time, so when leadership was told it would more time they bulked. Within a year I had prototyped an engine that could wrangle many of the views, but it lacked the support of many of the aging components built in Java that needed conversion.
No one invested in the migration due to a lack of leadership or vision. There was a gross under-appreciation for the user experience by leadership that banked on how they had amassed so much of the HR space, they didn't care if the UX was bad, because all they cared about is the data. What's worse, there are most likely many security vulnerabilities in the aging codebase that handles a bunch of employee data.
For me, not worked on but consulted/advised on, and I've seen this a few times: Passing all form data via GET requests.
Not only is this a security nightmare, it also limits data to the maximum length of a url (2048) — which leads to confusing errors if you didn't realize this.
This has always been advising startups run by people with minimal webdev and/or "real world" software development experience. Given my duty of advising/consulting, it generally is a matter of picking your battles to help the folks there get a sense on which issues to pay most attention to, because generally these codebases are a mess and you can'g fix everything.
A few years back: minified, obfuscated 'Backbone JS' code... 🫠🫠🫠
Marketing wanted us to change the styling or the links or something, can't remember now, must have blanked it out my memory!! Below is a sample of the sort of thing I was dealing with:
Hello I'm Sophie. I'm an operations specialist looking to make the transition into software and/or mobile app development. I have recently learnt SQL, HTML, CSS and JavaScript looking to upskill more
One long-ass ruby script with lots of system() calls to another ruby script but with different parameters to run different steps of a process; duplicated entirely into three separate projects that were all the same two scripts but with subtle differences.
The worst codebase I ever inherited was a hand rolled PHP application from the bad-old-days. Thousands of lines of in-line MySQLi and templates in a single file that handled POST and GET requests. Single character variable names. Unhelpful comments that were just a series of curse words. JOE detritus everywhere.
Critical company software, no source control, no local development strategy. All edited live on the FTP server.
Oh, I’ve definitely come across some messy codebases! The worst one I worked on was filled with spaghetti code—no documentation, inconsistent naming conventions, and everything was crammed into a few massive functions. Debugging was a nightmare, and any small change felt like it could break the entire system. It was a good lesson in the importance of clean, maintainable code and proper documentation!
Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
I joined a company and was introduced to the codebase. It was using JSPs with a custom build framework for data access. The owner of the business had built this custom framework, and was proud of it. The developers there had all been there longer than ten years. They worked online - meaning continuous video streaming by everyone during work hours. These developers were trapped because the codebase had fallen well behind the times in terms of Java and client side webapps. Making small changes was excruciatingly painful, meanwhile I was watching developers who no longer had career options cling to the rusting hulk of a codebase. While I don't think we should be jumping on every bandwagon of 'new technology' you need to adapt to the times. And for businesses there is a danger in getting invested in your own technologies and failing to adapt and update.
The worst I ever dealt with was GECOS, the OS for the GE635 computer in the late 1960s. All of you who are younger cannot imagine how bad code can be. For instance:
It was all assembly language.
There was no notion of good programming practice. For instance someone might examine the source for function FOO and decide that calling location FOO+2 would achieve some useful result. Of course this would break after future revision of FOO.
Code revisions were shipped once or twice a year. When bug fixes were needed between releases, they had to be distributed as binary patches. These had to be hand written by developers, without any tool support. Of course the patches were often wrong.
Yes, of course. This wasn't my first system.
I started just at the beginning of time sharing. Dartmouth Basic was new.
Hard disks we new. On the GECOS system a program such as a text editor took about 4K of 36 bit words.(~16KB) written in assembly language. (While we had Fortran and Cobol, they weren't suitable for writing interactive utilities or the OS.) When I started programming for this system there wasn't even a heap memory allocator (like malloc). I had to write my own. Working with memory constraints was probably the major programming problem.
There were no monitors. Everything online was done with printing terminals, like teletypes or IBM Selectric typewriter based terminals.
I'm a professional PHP, Python and Javascript developer from the UK. I've worked with Django, Laravel, and React, among others. I also maintain a legacy Zend 1 application.
The project I spend more time working on at my current job than any other:
Zend 1, so stuck on PHP 7.1 unless we get permission to migrate it to a newer fork
Fat controllers galore
No ORM, just hand rolled database objects with loads of horrible boilerplate to populate them
Wall to wall spaghetti jQuery for all the JavaScript
In the six and a half years I have been working on it I have integrated Composer, Codesniffer and Psalm, migrated many of the database queries to Eloquent, refactored many of the fat controllers, and rewritten some of the JavaScript to use React. Still a long way to go though.
While I did my internship at a graphic design agency, my boss asked me to add a new paragraph to the page.
What should have taken 30 seconds to do ended up taking a whole day. The former developer inserted the content of the website in HTML in a random order.
They used CSS absolute positioning to rearrange the content as required for all elements in dozens of pages.
I'm a coder who has worn a lot of hats, from individual contributor to lead engineer to "CTO" (yes, in quotes, make of that what you will!). I've a lot to learn and hopefully some to share as well.
It was a Node.js backend for a poker game. We contracted a game studio to build it, but then we had to jump in and save it when it became clear how rough it was. They actually forked one of their existing codebases for it, which had originally been written about a decade ago. It had all the stereotypical badness of early Node.js code like callback hell, plain JS (as opposed to TS), but it got worse:
They really didn't have any idea how to use databases. They represented a leaderboard as a single MongoDB document. They had an hourly cron job that pulled that document out of the database, sorted it, and stuffed it back into the database. That was how they sorted their leaderboard. For anyone who doesn't know Mongo that's basically like storing your leaderboard in a JSON column in a single row.
Their idea of observability was to JSON serialize the entire game state and write it to stdout whenever anything important happened. That could be megabytes for longer games (it shouldn't have been that much, but that's another story). Under any real load the servers would run out of memory buffering to stdout.
They had a "distributed architecture" and autoscaling, but the data wasn't sharded at all, so basically every server still had to receive and process every message, so the autoscaling was practically useless. No matter how many servers were running, it didn't have any more throughput than a single server (actually, adding more servers reduced throughput).
Overall it was just a big ball of mud. Extremely hard to change anything without breaking other miscellaneous stuff. Very hard to debug. Hard to reason about the code. We got it working well enough but it was still buggy and hard to do anything with. If the game had become popular, we would have gotten wrecked, even with all the improvements we did. There's only so much you can do.
I was rewriting app for public sector from C#, from outside it had a problem that when you hit the page it took around 10s to respond from server, but when it did cache the results it was reasonable fast, site had low traffic and lots of pages so you never hit the cache.
When I get to the code it had thousands of lines of code and boilerplate which were never used or done nothing and only few classes (each thousands of lines) which were doing something. Behind it was complex MSSQL database which nobody understands, tons of triggers and views.
It had awful SOAP API, which were sadly used by other services (created by same company), even SOAP API for write without documentation how it works.
Bonus was administration as some executable for client stations which nobody had source codes and which was working directly with MSSQL.
It took 3 months just to decipher old database, create meaningful new one and some migration script to copy data.
It's was 2022 when I started working on a codebase that was 1 year old. The backend was PHP, nothing against PHP, but it was still the kind where you've had to include other php files. Frontend was in plain jQuery. It was 2022. 2022!
A legacy codebase with legacy documentation, which even the original authors were frustrated with having to explain. It took weeks to get onboarded and it still did not work correctly.
A nodejs backend project repository which I got as a senior dev which had 3 different languages - purescript, javascript and typescript mixed without any kind of documentation or source control.
Every single file was repeated with some change to maintain version in the damn file name.The management wanted me to move it to a single language in a single week.
For those who don't know purescript is strongly typed and functional language which does not even have it's 1st version release yet
Public sector contractor code is always the worst possible thing, but there was one that really took the cake.
This was C#. There was an abstract base class a lot of classes inherited from. The subclasses all called a protected method in the abstract base class.
As designs go, that's not bad, right? We can bicker over the value of inheritance, but there are worse things, right?
No! There aren't! Because the way that the protected method in the abstract base was implemented is it was using reflection to get the class name from
thisand comparing the reflected name of the calling subclass using a switch statement to find the right implementation based on hardcoded strings of subclass names!I will die mad at that piece of code and how much more money that senior developer made than me.
I hate stuff like this
wow. That's unfathomably convoluted. Did that solve some sort of issue that implementing in the subclasses couldn't?
It did absolutely not lol.
One time I worked for an agency, which I won't name but will refer to as The Bad Place. The management decided that instead of giving us, the web folks, a website to build, they'd get a contractor in to do it. It was in the days where the designers (who only worked on magazines) would send you a PSD and say, "make it web".
Anyway, it was a photo competition site, where people could submit photos and they'd appear in a gallery.
The only thing I can say about the code that's positive is that it resisted SQL injections. Because it didn't let people sign up. When the contractor left, without the management agreeing to spend any money on QA, it turned out that most of the buttons on the site were images that did nothing, because they'd never specified what they should do.
The killer code though... anyone could submit a picture of any size and it'd store it and serve it, uncached, no CDN, for anyone to see. So, a lot of spam, broken images and nudity.
People didn't complain about the spam though, because the gallery page was coded in PHP using:
mysql_connect()SELECT *for()loop for pagination giving every 10 photos a wrapperdiv.If you can imagine this, it means that every picture ever uploaded was rendered to the page all at once.
We got 80,000 uploaded photos over the first weekend.
The contractor did not respond to email.
^ Codebase of a simple plugin from my previous company 🤮
lol
The code was created by a third party dev team five or six years before I joined the company.
The data structures were so unnecessarily complex that they were built with macros. The macros were probably generated from a spreadsheet (we found a spreadsheet that defined the macros) using something that is lost to time.
We're talking hundreds of macros. The macros have to use macros that run macros because the parameters for the macros are generated by macros. Some of the parameters in the macros are never used.
Why write C when you can just put everything in preprocessor instructions?
No unit tests. Practically no documentation.
This means that if we had wanted to change the structures at all we'd have to either reverse engineer the generator or go about it by hand, and then run two days worth of end to end tests to make sure we'd not broken anything.
Luckily I only ever had to read the code.
Agh that sounds painful!
It feels good to vent 😁
All my early projects are hot garbage codebases... I do look back sometimes to remind myself of how far I've come in my coding journey
Lol same
Once was hired as a Senior engineer to refactor a codebase for an app that handles sensitive employee data. I'm a full-stack JavaScript engineer with some experience in other languages and found myself in a sea of Java engineers that had chosen GWT, which is deprecated, and the company can't figure out how to roll off GWT onto a modern stack. I quickly became Principal in one year because I successfully architected and prototyped a solution for the company's dynamic form layouts in a JavaScript environment. I built it to be server-side renderable, but those words "server-side renderable" were "bad words" at the company. No matter no hard I tried to sell it, no Java engineer could wrap their head around dynamic forms being server-side rendered, so the project remained client-side rendered and performed better than the prior implementation.
Engineers had tried and failed to integrate React with GWT because all they did was swap out the components and not the engine. JavaScript engineers that were being hired had no idea where to begin because GWT is not documented well and it's Java. At times it felt like engineers were sabotaging the migration by making painful ways to migrate off GWT that took a long time, so when leadership was told it would more time they bulked. Within a year I had prototyped an engine that could wrangle many of the views, but it lacked the support of many of the aging components built in Java that needed conversion.
No one invested in the migration due to a lack of leadership or vision. There was a gross under-appreciation for the user experience by leadership that banked on how they had amassed so much of the HR space, they didn't care if the UX was bad, because all they cared about is the data. What's worse, there are most likely many security vulnerabilities in the aging codebase that handles a bunch of employee data.
For me, not worked on but consulted/advised on, and I've seen this a few times: Passing all form data via
GETrequests.Not only is this a security nightmare, it also limits data to the maximum length of a url (2048) — which leads to confusing errors if you didn't realize this.
This has always been advising startups run by people with minimal webdev and/or "real world" software development experience. Given my duty of advising/consulting, it generally is a matter of picking your battles to help the folks there get a sense on which issues to pay most attention to, because generally these codebases are a mess and you can'g fix everything.
lovely
A few years back: minified, obfuscated 'Backbone JS' code... 🫠🫠🫠
Marketing wanted us to change the styling or the links or something, can't remember now, must have blanked it out my memory!! Below is a sample of the sort of thing I was dealing with:
'use strict';function _0x30f8(){var _0x2de6f7=['Hey!\x20Give\x20this\x20thing\x20a\x20title.','Model','5267007PnMaoG','NoteCollection','51982bmypLe','random','929960cVahjY','author','NoteModel','219354XmrIkE','You\x20gotta\x20write\x20a\x20description,\x20duh!','isEmpty','850056xVAnlj','Put\x20your\x20name\x20in\x20dumb\x20dumb...','LocalStorage','extend','74BNrnsZ','825bexrUW','description','186JvwgBt','1631695lbCLVr'];_0x30f8=function(){return _0x2de6f7;};return _0x30f8();}var _0xc9e65e=_0x535d;(function(_0x54d5fa,_0xa4bef9){var _0x49fd76=_0x535d,_0x14a1f4=_0x54d5fa();while(!![]){try{var _0x2745f5=parseInt(_0x49fd76(0x181))/0x1*(-parseInt(_0x49fd76(0x180))/0x2)+-parseInt(_0x49fd76(0x179))/0x3+parseInt(_0x49fd76(0x17c))/0x4+parseInt(_0x49fd76(0x184))/0x5+-parseInt(_0x49fd76(0x183))/0x6*(-parseInt(_0x49fd76(0x174))/0x7)+parseInt(_0x49fd76(0x176))/0x8+-parseInt(_0x49fd76(0x172))/0x9;if(_0x2745f5===_0xa4bef9)break;else _0x14a1f4['push'](_0x14a1f4['shift']());}catch(_0x23fda5){_0x14a1f4['push'](_0x14a1f4['shift']());}}}(_0x30f8,0x2ff56));function _0x535d(_0x439dcb,_0x125d0c){var _0x30f895=_0x30f8();return _0x535d=function(_0x535dc9,_0x2d4a0a){_0x535dc9=_0x535dc9-0x172;var _0x3ba041=_0x30f895[_0x535dc9];return _0x3ba041;},_0x535d(_0x439dcb,_0x125d0c);}APP[_0xc9e65e(0x178)]=Backbone[_0xc9e65e(0x186)][_0xc9e65e(0x17f)]({'defaults':{'title':'','description':'','author':'','id':_[_0xc9e65e(0x175)](0x0,0x2710)},'validate':function(_0x5267d3){var _0x42dbb1=_0xc9e65e,_0x4a1eab={};if(!_0x5267d3['title'])_0x4a1eab['title']=_0x42dbb1(0x185);if(!_0x5267d3[_0x42dbb1(0x182)])_0x4a1eab['description']=_0x42dbb1(0x17a);if(!_0x5267d3[_0x42dbb1(0x177)])_0x4a1eab[_0x42dbb1(0x177)]=_0x42dbb1(0x17d);if(!_[_0x42dbb1(0x17b)](_0x4a1eab))return _0x4a1eab;}}),APP[_0xc9e65e(0x173)]=Backbone['Collection'][_0xc9e65e(0x17f)]({'localStorage':new Backbone[(_0xc9e65e(0x17e))](_0xc9e65e(0x173)),'model':APP[_0xc9e65e(0x178)]});How does ANYONE work with that!!? Wow!
With any luck they don't 😭😭😭
But to be honest it wasn't anything major we had to do to it, thankfully!
One long-ass ruby script with lots of
system()calls to another ruby script but with different parameters to run different steps of a process; duplicated entirely into three separate projects that were all the same two scripts but with subtle differences.The worst codebase I ever inherited was a hand rolled PHP application from the bad-old-days. Thousands of lines of in-line MySQLi and templates in a single file that handled POST and GET requests. Single character variable names. Unhelpful comments that were just a series of curse words. JOE detritus everywhere.
Critical company software, no source control, no local development strategy. All edited live on the FTP server.
Ohhh this brings back memories from some of my first (thankfully fairly low stakes) projects I worked on :D
Oh, I’ve definitely come across some messy codebases! The worst one I worked on was filled with spaghetti code—no documentation, inconsistent naming conventions, and everything was crammed into a few massive functions. Debugging was a nightmare, and any small change felt like it could break the entire system. It was a good lesson in the importance of clean, maintainable code and proper documentation!
I joined a company and was introduced to the codebase. It was using JSPs with a custom build framework for data access. The owner of the business had built this custom framework, and was proud of it. The developers there had all been there longer than ten years. They worked online - meaning continuous video streaming by everyone during work hours. These developers were trapped because the codebase had fallen well behind the times in terms of Java and client side webapps. Making small changes was excruciatingly painful, meanwhile I was watching developers who no longer had career options cling to the rusting hulk of a codebase. While I don't think we should be jumping on every bandwagon of 'new technology' you need to adapt to the times. And for businesses there is a danger in getting invested in your own technologies and failing to adapt and update.
The worst I ever dealt with was GECOS, the OS for the GE635 computer in the late 1960s. All of you who are younger cannot imagine how bad code can be. For instance:
It was all assembly language.
There was no notion of good programming practice. For instance someone might examine the source for function FOO and decide that calling location FOO+2 would achieve some useful result. Of course this would break after future revision of FOO.
Code revisions were shipped once or twice a year. When bug fixes were needed between releases, they had to be distributed as binary patches. These had to be hand written by developers, without any tool support. Of course the patches were often wrong.
I think you have many memories to tell. HDD, database, floppy disk, monitor quality, basic, memory limitations, etc.
Yes, of course. This wasn't my first system.
I started just at the beginning of time sharing. Dartmouth Basic was new.
Hard disks we new. On the GECOS system a program such as a text editor took about 4K of 36 bit words.(~16KB) written in assembly language. (While we had Fortran and Cobol, they weren't suitable for writing interactive utilities or the OS.) When I started programming for this system there wasn't even a heap memory allocator (like malloc). I had to write my own. Working with memory constraints was probably the major programming problem.
There were no monitors. Everything online was done with printing terminals, like teletypes or IBM Selectric typewriter based terminals.
The project I spend more time working on at my current job than any other:
In the six and a half years I have been working on it I have integrated Composer, Codesniffer and Psalm, migrated many of the database queries to Eloquent, refactored many of the fat controllers, and rewritten some of the JavaScript to use React. Still a long way to go though.
While I did my internship at a graphic design agency, my boss asked me to add a new paragraph to the page.
What should have taken 30 seconds to do ended up taking a whole day. The former developer inserted the content of the website in HTML in a random order.
They used CSS absolute positioning to rearrange the content as required for all elements in dozens of pages.
This gives a whole new meaning to CSS (every element cascading on top of the last!) 😂
It was a Node.js backend for a poker game. We contracted a game studio to build it, but then we had to jump in and save it when it became clear how rough it was. They actually forked one of their existing codebases for it, which had originally been written about a decade ago. It had all the stereotypical badness of early Node.js code like callback hell, plain JS (as opposed to TS), but it got worse:
I was rewriting app for public sector from C#, from outside it had a problem that when you hit the page it took around 10s to respond from server, but when it did cache the results it was reasonable fast, site had low traffic and lots of pages so you never hit the cache.
When I get to the code it had thousands of lines of code and boilerplate which were never used or done nothing and only few classes (each thousands of lines) which were doing something. Behind it was complex MSSQL database which nobody understands, tons of triggers and views.
It had awful SOAP API, which were sadly used by other services (created by same company), even SOAP API for write without documentation how it works.
Bonus was administration as some executable for client stations which nobody had source codes and which was working directly with MSSQL.
It took 3 months just to decipher old database, create meaningful new one and some migration script to copy data.
It's was 2022 when I started working on a codebase that was 1 year old. The backend was PHP, nothing against PHP, but it was still the kind where you've had to include other php files. Frontend was in plain jQuery. It was 2022. 2022!
A legacy codebase with legacy documentation, which even the original authors were frustrated with having to explain. It took weeks to get onboarded and it still did not work correctly.
A nodejs backend project repository which I got as a senior dev which had 3 different languages - purescript, javascript and typescript mixed without any kind of documentation or source control.
Every single file was repeated with some change to maintain version in the damn file name.The management wanted me to move it to a single language in a single week.
For those who don't know purescript is strongly typed and functional language which does not even have it's 1st version release yet
Every codebase that I touched.
Pretty much everyone I ever architected when I revisited it several years later... The world moves on; in one case, my 20+ year-old code hadn't.
Anything in ABAP.
Although it’s unpleasant working on bad codebases, it’s often a great learning experience
My own codebase. In the last few months, I've realized that I've spent a lot of time over-analyzing my code, and that's somehow made it worse.
I'm looking for someone to make an app. Get paid. Contact me.