Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

291–300 of 601 posts

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

#291

Post by oraguy »

Maro wrote: post #284
nathan_f77 wrote: post #228

Earlier quoted context omitted.

That is absolutely insane. I can't even begin to imagine the complexity of that codebase. I thought my Rails test suite was slow because it takes 4 minutes. If I wrote it in C or C++ it would probably be 10 seconds. I can't imagine a C/C++ application where the test suite takes 20-30 hours on a test farm with 100-200 servers. And if you can break 100-1000 tests with a single change, it doesn't like things are very mo…

It's a good exercise to imagine how the job would be sold. Things like this would definitely not come up in the interview process, instead they would sell you on "you get to work on a cutting-edge db kernel that is running most of the Fortune 100s" or sth like that, which is true (!), but doesn't describe the day to day. The best way to guess this is to extrapolate from the interview questions. If they ask you a lot…

On the contrary, the interview was an ordinary one. The screening round consisted of very basic fizzbuzz type coding ability checks: Reversing a linked list, finding duplicates in a list, etc.

Further rounds of interviews covered data structure problems (trees, hashtables, etc.), design problems, scalability problems, etc. It was just like any other interview for software engineering role.

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

#292

Post by oraguy »

osrec wrote: post #272
nathan_f77 wrote: post #228

Earlier quoted context omitted.

That is absolutely insane. I can't even begin to imagine the complexity of that codebase. I thought my Rails test suite was slow because it takes 4 minutes. If I wrote it in C or C++ it would probably be 10 seconds. I can't imagine a C/C++ application where the test suite takes 20-30 hours on a test farm with 100-200 servers. And if you can break 100-1000 tests with a single change, it doesn't like things are very mo…

Hell for the proactive go-getters, but paradise for people who enjoy any excuse for a bit of justifiable down time! Q: Are you busy? A: Yes, in the middle of running tests...

That would have been fun but in reality there was no downtime. Developers like me were expected to work on two to three bugs/features at a time and context switch between them.

If I submit my test jobs today to the farm, the results would come one or two days later, so I work on another bug tomorrow, and submit that. Day after tomorrow, I return to the first bug, and so on.

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

#293

Post by mannykannot »

pmarreck wrote: post #113
Izkata wrote: 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 doesn't think for you, it merely validates your own existing understanding/mental model and forces you to come up with it upfront. This is hardly a thing to be mistrustful about, unless you work with idiots.

You are right about that, but having code that passes a given test suite doesn't say anything about its secondary qualities, such as whether it can be understood. In theory, a failing test could improve your understanding of the situation, allowing you to refactor your initial pass at a solution, but I would bet that on this particular code base, the comprehension-raising doesn't go far enough, in most cases, for this to be feasible.

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

#295

Post by kieckerjan »

YeGoblynQueenne wrote: post #277

There should be an award. Like the Turing award, but not quite. The trophy should be a plate of spaghetti, in gold.

Hell yeah! Like the Golden Raspberry Awards or the Bad Sex Awards, but, you know, for code!

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

#296

Post by oraguy »

gnulinux wrote: post #49
eismcc wrote: 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.

> 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 concept of layered code (like a virtual operting system layer at the bottom, a memory management layer on top of that, a querying engine on top of that, and so on) but over the years, people violated layers and wrote code that called an upper layer from lower layer leading to a big spaghetti mess. A change in one module could cause a very unrelated module to fail in mysterious ways.

Every test was almost always an integration test. Every test case restarted the database, connected to the database, created tables in it, inserted test data into it, ran queries, and compared the results to ensure that the observed results match the expected results. They tried to exercise every function and every branch condition in this manner with different test cases. The code coverage was remarkable though. Some areas of the code had more than 95% test coverage while some other areas had 80% or so coverage. But the work was not fun.

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

#297

Post by mannykannot »

carlmr wrote: post #210
sooheon wrote: post #114

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.

It is not be a good analogy for TDD as properly practiced, but it seems to be very fitting for the situation described at the top of this thread, and that is far from being a unique case.

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

#298

Post by jonathanstrange »

gnulinux wrote: post #42

We have absolutely no idea how to write code. I always wonder if it's like this for other branches of engineering too? I wonder if engineers who designed my elevator or airplane had "ok it's very surprising that it's working, let's not touch this" moments. Or chemical engineers synthesize medicines in way nobody but a rockstar guru understands but everyone changes all the time. I wonder if my cellphone is made by mac…

Not exactly relevant to the overall discussion but I've been dreaming for a long time about programming an elevator such that it arrives faster and skips other floors if a user frantically pushes the call button repeatedly. Same for traffic lights with push buttons.

Maybe it's a good thing that I'm not an engineer.

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

#299

Post by TickleSteve »

danmaz74 wrote: post #246
gnulinux wrote: post #49

Earlier quoted context omitted.

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.

I beg to differ. Having to run the full test suite to catch significant errors is an indication that the software design isn't (very) modular, but it has nothing to do with unit tests. Unit tests do not replace service/integration/end to end tests, they only complement them - see the "test pyramid". I think it's important to point this out, because one of the biggest mistakes I'm seeing developers do these days is re…

(terminology nazi mode)

"... is an indication that the software design isn't (very) decoupled ".

You can be modular without being properly decoupled from the other modules.

Post reply on HN