Live data from Hacker News

Ask HN: What's the largest amount of bad code you have ever seen work?

news.ycombinator.com

431–440 of 601 posts

Re: Ask HN: What's the largest amount of bad code you have ever seen work?

#431
post #62

Earlier quoted context omitted.

A sentiment among members of a former team was that automated tests meant you didn't need to write understandable code - let the tests do the thinking for you. This, and stuff like your story, are why I don't trust people who promote test-driven development as the best way to write clean APIs.

TDD need to die. This is a curse. There should be integration tests along with some property based tests and fuzzy tests. Usually catches a lot of things.Invest in monitoring and alerts too. TDD is like relying on debugger to solve your problem. Is debugger a good tool? yes,it is a great tool. But using it as an excuse to avoid understanding what happens under the hood is plain wrong. The problem lies in industry whe…

I think TDD is the best way to develop (yet). Obviously tests are code, and if you write crappy highly-coupled tests you will end up with only much more messy code. This is a clear example of bad testing. The greatest advantage of TDD is in design, everything should be modular and easy to unit test, so you could:

- reproduce bug and verify your bugfix in matter of ms with proper unit test

- understand what code does

- change and refactor code whenever you want

You can tell from what is written that they are not following TDD. Redesign that codebase in an easy and clean to test design would require an exponential effort and time compared to have it done step by step, but it would be worth it

Re: Ask HN: What's the largest amount of bad code you have ever seen work?

#432
post #18

Oracle Database 12.2. It is close to 25 million lines of C code. What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap. Very complex pieces of logic, memory management, context switching, etc. are all held together with thousand…

> The only reason why this product is still surviving and still works is due to literally millions of tests!

Lesson learned. Always write tests. Your business will depend on it.

Re: Ask HN: What's the largest amount of bad code you have ever seen work?

#433
post #168

I am maintaining one application in construction industry space. That application was created 25 years ago by construction worker that never wrote single line of code before, but because he caused a lot of problems on construction site they give him Programming 101 book and let him build it. 15 years later the app was close to half milion lines long of huge bowl of spaghetti code. Only comments in whole codebase were…

I have to salute this construction worker for building a solution that is apparently so valuable for the business that they can’t simply replace or rewrite it. This probably means that it solves a real problem for them, and adding 30.000 lines of code per year without any formal training or much tooling is no small feat either. I understand the criticisms and laughs here from the “real” software developers, but damn…

Somewhere out there, there's a software developer who was assigned the task of building the team's office using 30,000 bricks, making all kind of spaghetti patches to prevent it from falling over, and the construction workers are laughing about it on a construction worker forum.

Re: Ask HN: What's the largest amount of bad code you have ever seen work?

#434
post #296

Earlier quoted context omitted.

> Tests that run for 30 hours is an indication that nobody bothered writing unittests. Yes, they were not unit tests. There was no culture of unit tests in the Oracle Database development team. A few people called it "unit tests" but they either said it loosely or they were mistaken. Unit test would not have been effective because every area of the code was deeply entangled with everything else. They did have the con…

I'm amazed that it had that many tests that took that long, but ONLY had 80-95% coverage. I understand the product is huge, but that's crazy.

Writing tests for error handling can be a pain. You write your product code to be as robust as possible but it isn't always clear how to trigger the error conditions you can detect. This is especially true with integration tests.

Re: Ask HN: What's the largest amount of bad code you have ever seen work?

#435
post #18

Oracle Database 12.2. It is close to 25 million lines of C code. What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap. Very complex pieces of logic, memory management, context switching, etc. are all held together with thousand…

> The only reason why this product is still surviving and still works is due to literally millions of tests! Lesson learned. Always write tests. Your business will depend on it.

One one hand, sure. They're still able to ship a working product despite having an abysmal code base. That's an excellent end result that must not be underestimated. Perhaps the problem that code base solves is really that difficult and there's no other way.

But on the other hand, over-reliance on tests is one of the reasons they ended up in this situation in the first place. It's like the car safety engineer's joke - How do you make cars safer? Install a knife in the middle of the steering wheel pointed at the driver.

When we're too sure that some safety feature will save us, we forget to be careful.

Re: Ask HN: What's the largest amount of bad code you have ever seen work?

#436
post #62

Earlier quoted context omitted.

A sentiment among members of a former team was that automated tests meant you didn't need to write understandable code - let the tests do the thinking for you. This, and stuff like your story, are why I don't trust people who promote test-driven development as the best way to write clean APIs.

TDD need to die. This is a curse. There should be integration tests along with some property based tests and fuzzy tests. Usually catches a lot of things.Invest in monitoring and alerts too. TDD is like relying on debugger to solve your problem. Is debugger a good tool? yes,it is a great tool. But using it as an excuse to avoid understanding what happens under the hood is plain wrong. The problem lies in industry whe…

I very much agree.

I remember when i realized that TDD shouldn't have such weight in our development as it had gotten (when it was high on the hype curve).

It was when we starting using a messaging infrastructure that made everything much more reliable and robust, and trough which we could start trusting the infrastructure much more (not 100% though, of course).

It made me realize that the reason why we did this excessively large amount of tests (1800+) was because the fragile nature of a request/response-based system and we therefore "had to make sure everything worked".

What I'm trying to get at here is thar TDD assumed the role of a large safety net to a problem we should have addressed in a different manner. After introducing the messaging, we could replay messages that had failed. After this huge turning point tests were only used for what they should have only been used for - ensuring predictable change in core functionality.

(our code also became easier to understand and more modular, but that's for another time...)

Re: Ask HN: What's the largest amount of bad code you have ever seen work?

#437

I once had to look at a client’s code to determine if/how we’d go about taking over their application. Their only developer threatened to quit and this is when they realised it would be best to outsource this and reduce the bus factor. It was a huge folder (not repo - and there were zip files of different “versions” of the code in there). The main monster was a huge Visual Studio solution with hundreds of targets, on…

Ha!

Are you me? :-)

Had almost the same experience, minus the database. Friend of the owner wanted to buy a company and asked us to evaluate their code to see if it was maintainable enough to add new features. I got a zip of hundreds of firmware projects each representing a different version. They were all on the same basic platform but with different hardware features #ifdef'd, or customized for a particular customer. The code itself wasn't that bad (not that good either!), but their developer clearly had no idea what Version Control meant.

In the end I gave the thumbs up and he bought the company, then ended up having to redesign the product from scratch since much of the originally designed-in components were no longer available. He did his Due Diligence for the software, but ignored the hardware side!

Re: Ask HN: What's the largest amount of bad code you have ever seen work?

#438
post #186

Earlier quoted context omitted.

I had a very very similar experience. I saw the craziest code in my entire career while debugging performance issues. Even though they were using a PHP MVC framework, they were pulling every record from a db table to iterate over to find the record using PHP string compare functions. I still can't believe it. The dev shop I worked for back then was even in the habit of hiring multiple teams for the same project in th…

> pulling every record from a db table to iterate over to find the record using PHP string compare functions As horrible as this sounds, this is actually good from a refactoring point of view because it should be straightforward to rewrite it to use actual queries.

Perhaps technically true, but the entire point of the MVC is you can do simple record retrievals with a single line of code using auto generated active record models. One line vs a monstrous dirty function isn't acceptable.

Re: Ask HN: What's the largest amount of bad code you have ever seen work?

#439
Here's a story I haven't shared in awhile.

One of my first gigs actually getting paid to code was getting hired on as a last ditch effort to save what was (unknown to me at the time) a failing business. It was a company that basically relisted real-estate auctions on their own site, coded entirely in PHP, by a single developer who had read "How to Code PHP in 24 Hours". They had one client that was basically keeping them afloat. It was so disorganized that at one point I was tasked with making a quick YouTube commercial in Adobe Premier for a client, showing off the features of our whitelabel product with their logos, edited from a stock template. I do not know Adobe Premier. I digress.

The main PHP file (yes) was 20,000 lines of code. Want to add a new feature? Copy that file into a new file and save it as newfeature.php. Database operations weren't transactional, there was no change management, and for about a week we were using production systems to code until development environments were made for us.

There was other shady stuff going on too, like using over a hundred proxy accounts to scrape content from other listing sites. I refused to touch or even look at that logic in the codebase, and it was always talked about in kind of a hushed way. I was young, didn't know any better, would nope the eff out if a similar opportunity came along at this stage in my career.

They folded shortly after laying off pretty much everyone but the CEO and the lone coder. Dumpsterfire would be an understatement, but my coworkers were chill and helped make the best out of a bad situation.

EDIT: Oh yeah! I forgot to mention the hardcoded password the was site wide that we used as a sort of "impersonation" feature. You could type in any user account and this password, and it would log you in no problem. No, we did not have auditing controls.

Re: Ask HN: What's the largest amount of bad code you have ever seen work?

#440
post #251

Earlier quoted context omitted.

Totally unsurprising if you've ever worked with Oracle. The layers upon layers of legacy cruft are plainly visible even in simple things like the GUI installers.

The fact that the first version shipped in 1979 has to contribute to this as well. The field of software engineering has matured a lot since then.

I mean, PostgreSQL can trace its roots back to 1982's INGRES ... and UNIX started in 1969.

There are quite a few very old projects that don't have the same level of cruft as Oracle; it epitomises a Sales Division driven culture.

How many of those switches (that now need to be supported and tested) are because some functionality was promised to a large contract, and so it just had to be done? I would wager a good number.

Post reply on HN