Live data from Hacker News

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

news.ycombinator.com

251–260 of 601 posts

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

#251
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…

Really surprising considering that Oracle is the standard for serious enterprise databases. Not really surprising when you consider Oracle's other bug ridden offerings (probably not as thoroughly tested). Makes me fear for Oracle 18c.

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.

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

#252
post #210

Earlier quoted context omitted.

Rich Hickey called it guard rail driven programming. You'll never drive where you want to go if you just get on the highway and bump off the guard rails.

Except that's a really bad analogy. It's more like you set up guard rails, and every time your vehicle hits a guard rail you change the algorithm it uses for navigation until it can do a whole run without hitting a guard rail. I've experienced myself how the code quality of proper TDD code can be amazing. However it needs someone to still actually care about what they're doing. So it doesn't help with idiots.

I don't think it's a generous analogy, but it's poking fun at being test DRIVEN, rather than driver driven. I think he'd agree with you that it's the thinking and navigating and "actually caring about what they're doing" that matters. Tests are a tool to aid that. Tests don't sit in the driver's seat.

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

#253

Here's a metaquestion: Is it possible for any codebase to NOT eventually (given enough time) become a crufty pile of garbage? I suspect (but have no real evidence... yet) that SOME of this spaghetti garbage is due to the traits of procedural, OOP, mutable languages. But this would then imply that things like functional-language codebases have much longer lifespans... and I don't have evidence for that... but I'm hopi…

https://en.wikipedia.org/wiki/Software_entropy

Edit: I actually like the following article much better, found it in the See Also section of the link above. https://en.wikipedia.org/wiki/Software_rot

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

#254
post #27

Earlier quoted context omitted.

At least there are tests!

Tests that run for 30 hours is an indication that nobody bothered writing unittests. If you need to run all tests after changing X, it means X is NOT tested. Instead you need to rely on integrations tests catching Xs behavior.

In large systems you can unit test your code within an inch of its life and it can still fail in integration tests.

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

#255

As a budding programmer (hobbyist), what can I do not to fall into the mistakes others talk about in the comments? Is there any particular set of mental habits that could lessen the chance of spaghetti occurring, or is it just a matter of when rather than if?

The most important thing is to be on the lookout for spaghetti code (or other big chunks of hard-to-maintain code), and do something against it.

There's lots of materials on how to refactor code (improving its structure without changing functionality), including blogs, books and video lectures.

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

#256

As a budding programmer (hobbyist), what can I do not to fall into the mistakes others talk about in the comments? Is there any particular set of mental habits that could lessen the chance of spaghetti occurring, or is it just a matter of when rather than if?

The best way to learn how not to write spaghetti code is working on spaghetti somebody else wrote. Every big project has some corner with sub-par code quality, so you could volunteer to clean something up, e.g. in Libreoffice or Firefox.

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

#257

Here's a metaquestion: Is it possible for any codebase to NOT eventually (given enough time) become a crufty pile of garbage? I suspect (but have no real evidence... yet) that SOME of this spaghetti garbage is due to the traits of procedural, OOP, mutable languages. But this would then imply that things like functional-language codebases have much longer lifespans... and I don't have evidence for that... but I'm hopi…

It's mostly a function of the effort put into the quality of the code base.

Currently, I work (among other things) on a 25 year old code base that acts as an interactive, terminal-based interface for a CMDB.

It has its problems (like mostly not using the exception mechanism of the programming language it's implemented in; probably wasn't very reliable back then, or maybe didn't exist), but all in all it's OK to work with. Most changes touch only 1 to 3 files, most of which are pretty short (There are "here be dragon" areas, but not too many.

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

#259
I once had to wade into a PHP app for a government procurement website that was just horrifyingly messy. I used to maintain records for the highest line number on which the opening tag appeared in a template (well into the thousands) and the highest number of opening/closing PHP tags (hundreds in a single file). There was no structure beyond bunging stuff in the session and hoping it all hung together.

The app ran on Mac servers.

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

#260
I was given the opportunity to work with iOS at one of my former employers and I quickly agreed (I was a backend developer back then). It was a rather popular application at a rather large Austrian media company, with around 50k unique monthly users.

Boy did I regret that decision!

- 100KLOC

- Initial development outsourced to India. Comments, variable names in Indian.

- Subsequent development outsourced to Belarus. Add comments, variable names in Russian.

- "Why use ObjC OO features when we can write buggy and incoherent C"?

- Global, implicit state everywhere. Tapped on something? Hope it didn't mess up the state you are relying on.

- Obviously no tests, and no testers.

- Inheritance chains of up to 20 classes.

- iOS kindly forces MVC, but you can obviously write empty controllers and all spaghetti-logic into your views. Needless to say, that was what they did.

- Complete lack of proper structure. Several views iterated up their parent controllers to the desired one, grabbed its views, iterated over them until the right view was found and something was done to that view.

- Building and running the application was controlled by 10+ env variables (the other dev was fired after he pushed a dev build to the App store, which mysteriously passed review. "Whoopsie, forgot to set one of the env variables correctly").

- about 80% of the logic was copy-pasted for the iPad build instead of reusing anything. It was not a different target, it was a separate project.

Post reply on HN