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

461–470 of 601 posts

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

#461

Post by SomeCallMeTim »

Ace17 wrote: post #172
thepp1983 wrote: post #53

Earlier quoted context omitted.

In reality there often isn't time. Getting it done > Getting it done properly as far a management is concerned.

Ever had this discussion with a coworker? Coworker: "I hadn't enough time to do it right" You: "Given enough time, how would you do it differently?" Coworker: "............" (crickets) IMHO it's not related to deadlines only ; the "not enough time" argument is often a comfortable fallacy, keeping us from facing the limits of our current skills. I found it to be especially true with testing. I've lost the count of how…

Unlike your coworker, I _always_ have a plan. Often a dozen of them. With various pros and cons for each.

But also unlike your coworker, I probably _figured out how to do it right_ in the time given. It's pretty rare that I don't have time to do it right; it does happen (especially with extreme instances of scope creep and requirements drift), but it's rare.

Which I guess is your point? The time excuse is just an excuse, and a good developer writes good code.

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

#462

Post by int_19h »

ddfx wrote: post #431
acroback wrote: post #415

Earlier quoted context omitted.

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…

In my opinion, the only thing that is valuable about unit tests is more appropriately captured in form of function, class and module contracts (as in "design by contract"). Unfortunately very few languages are adopting DbC.

Functional tests now, that's another matter. But a lot of TDD dogmatism is centered on unit tests specifically. And that results in a lot of code being written that doesn't actually contribute to the product, and that is there solely that you can chop up the product into tiny bits and unit test them separately. Then on the test side you have tons of mocks etc. I've seen several codebases where test code far exceeded the actual product code in complexity - and that's not a healthy state of affairs.

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

#463

Post by int_19h »

TickleSteve wrote: post #344
mooreds wrote: post #311

Earlier quoted context omitted.

Love the idea of this. In my experience it's far easier to introduce testing by focusing on unit testing complicated, stateless business logic. The setup is less complex, the feedback cycle is quick, and the value is apparent ("oh gosh, now I understand all these edge cases and can change this complicated code with more confidence"). I think it also leads to better code at the class/module/function level. In my exper…

In general, I test those things that relate to the application, not those about the implementation. i.e. Test business logic edge-cases, don't test a linked-list implementation... that's just locking your design in.

Writing functional tests is easy when you have a clear spec. If you do, tests are basically the expression of that spec in code. Conversely, if they're hard to write, that means that your spec is underspecified or otherwise deficient (and then, as a developer, ideally, you go bug the product manager to fix that).

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

#465

Post by c3534l »

acroback wrote: post #415
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 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…

And yet tests seem to have made this massive garbage heap actually work and enable a lump of spaghetti to continue to operate as a viable product. It doesn't mean you should write bad code, but it seems like if it can make even the most awful of code viable, then that's a pretty good system. The fact that modern medicine allows the most beat up and desperate to continue to live on isn't an indictment against medicine, it's a testament to it. Don't write bad code, sure. We can all agree to that. Don't prioritize testing? Why? To intentionally sabotage yourself so that you're forced to rewrite it from scratch or go out of business?

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

#466

Post by oraguy »

srkigo wrote: post #445
oraguy wrote: 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…

How can it have millions of tests with 25 million lines of code? How many lines of code is there including the code in the tests?

The 25 million lines of code is only the source code of Oracle Database written in C.

The test cases are written in a domain specific language named OraTst which is developed and maintained only within Oracle. OraTst is not available outside Oracle. The OraTst DSL looks like a mixture of special syntax to restart database, compare results of queries, change data configuration, etc. and embedded SQL queries to populate database and retrieve results.

I don't know how many more millions of lines of code the tests add. Assuming every test takes about 25 lines of code on an average (every test used to consume about half of my screen to a full screen), we can estimate that the tests themselves consume close to another additional 25 million lines of code to 50 million lines of code.

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

#467

Post by arwhatever »

dejv wrote: 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…

"lava flows" anti-pattern

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

#468

Post by lojack »

iopq wrote: post #454
lojack wrote: post #451

Earlier quoted context omitted.

I'm confused by your comment. Your premise is that TDD should die, and your support is comparing it to a "great tool". Should TDD really die, or should people just stop treating things as a silver bullet? I personally love TDD, it helps me reason about my interfaces and reduces some of the more cumbersome parts of development. I don't expect everyone to use TDD and I don't use it all the time. Similarly I'd never tel…

The thing is, when I spend a lot of time thinking about how to make my program type-safe all of my unit tests become either useless or no-ops Integration tests easily survive refactoring, on the other hand

Unit tests are a side effect of TDD, they don't have to be the goal. I'd find value out of TDD even if I deleted all of my tests after. It sounds like your problems are around unit tests, and that is neither something required to TDD nor is it something limited to just TDD.

The problem with integration tests is they are slow and grow exponentially. If they aren't growing exponentially then there's probably large chunks of untested code. Unit tests suffer their own problems, like you said they can be useless because of a reliance on mocking, they can also be brittle and break everywhere with small changes.

Ultimately any good suite of tests needs some of both. Unit tests to avoid exponential branching of your integration tests, and integration tests to catch errors related to how your units of code interact. I've experienced plenty of bad test suites, many of them are because of poorly written unit tests, but its often the poorly written integration tests that cause problems as well. As with most things, its all about a healthy balance.

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

#469

Post by lojack »

int_19h wrote: post #462
ddfx wrote: post #431

Earlier quoted context omitted.

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…

In my opinion, the only thing that is valuable about unit tests is more appropriately captured in form of function, class and module contracts (as in "design by contract"). Unfortunately very few languages are adopting DbC. Functional tests now, that's another matter. But a lot of TDD dogmatism is centered on unit tests specifically. And that results in a lot of code being written that doesn't actually contribute to…

In more recent times I've seen some growth in interest around contract testing. Unit tests are immensely more useful when paired with contract tests, but unfortunately without them they tend to be more of a hassle. At its essence integrations are a form of a contract, but those suffer their own problems. In rspec you have 'instance_double' which is a form of a contract test as well, but not really sufficient for proper testing IMO. The current state from what I've seen is a little lackluster, but I wouldn't be surprised to see a growth in contract testing libraries for a variety of languages popping up.

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

#470

Post by rocfreddy »

I worked for a cell phone company. They had a large piece of software that is used by all customer-facing employees to manage accounts (billing, network, provisioning). Over its life, the software had been rewritten in many languages. Prior to my joining the team, someone thought to take a .NET application and rebuild it as a web application (Spring MVC and ExtJS4).

The first day on the team, before even looking at the code base, I ask our development lead what unit testing framework we are using for the Java code and what we are using for the front end code. He gives me this funny look and tells me to speak the guy onboarding me. I of course go and ask the lead onboarding me and he gives me an answer that turned my world upside down.

"Automated testing is a waste of time. You will spend too much time writing test then developing code and delivering stories to the business"

I need to point out that this guy eventually goes on to an executive level position. proving that it is not the quality of work you deliver, but the optics of delivering quality software that counts in large corporations. I digress.

I receive my SVN credentials later that day and come to the realization that I have made a very poor career choice. The front end code alone is over 5k Javascript files with functions spanning thousands of lines long all full with 100's of nested asynchronous callbacks. Not only is the code crap, but the tools that we had were not used correctly. For example comments.

//01/01/2018 - Fix bug - Begin //01/01/2018 - Fix bug - End

The code base was riddled with these. What story was this for? would have been useful to pull the Jira story and see what you were trying to do. I guess I'll spend the day going through your 5k line function that does everything, but nothing. Or, better yet, let me check the SVN commit date. Maybe they committed some good notes for me there.

01/01/2018 - Fix bug

Damnit!

I did my year, which is the minimum you can be in a job before posting out. I left without a second thought. When I left the business was complaining because the testing team was larger than the development team. I wonder why?

Post reply on HN