Live data from Hacker News

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

news.ycombinator.com

451–460 of 601 posts

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

#451
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'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 tell someone debuggers should die and they should never use a debugger if thats something that would help them do their job.

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

#452

Earlier quoted context omitted.

Why not both?

Yes, both. But maybe one is more important?

I'd argue the tests is more important for example Oracle is still the leading commercial DB, If your product works people will buy it.

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

#453
post #62
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…

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.

I don't see how this is an argument against TDD. Apparently a whole slew of things went wrong in this project but that doesn't imply that testing is the cause of them.

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

#454
post #451

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'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

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

#455
post #431

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…

I had some tests on my codebase, but eventually only documentation and integration tests remained.

So let's look at a simplified example.

https://bitbucket.org/iopq/fizzbuzz-in-rust

My tests are in the test folder. They are actually superfluous since integration tests test for the same thing.

I cannot break up the program in a way that would unit test a smaller piece of it in more detail. They only tests I can add would be to test the command line driver

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

#456
post #431

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…

A unit test is the least useful kind of test. It requires your design to be "easy to unit test" instead of simple, and if you change something and have to rewrite the test you might miss some logic in both pieces.

Plus the tests never break on their own because they're modular, and each time you run a test that was obviously going to pass, you've wasted your time.

As long as you have code coverage, better to have lots of asserts and real-world integration tests.

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

#457
post #187

I took over a Perl project where every SQL call was an exec to a java program which would make the query. The largest madness was a J2EE mess where persistence was achieved by taking your current object, sending a message bean to the server, it would touch the database and return the result which was being polled for (making it synchronous). The amazing thing is that the client and the server were the same J2EE insta…

IMHO sometimes it's fine to use messaging within an application that runs on 1 device, purely for decoupling purposes.

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

#458

Earlier quoted context omitted.

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.

Hmmm... you have a point, but then, shouldn't it be "decoupled into modules"?

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

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

You've violated the terms of service of Oracle Database by insinuating the codebase quality is in any way not superior to any and all competitors. No benchmarks or comparisons may be performed on the Oracle Database Product under threat of grave bodily harm at the discretion of our very depraved CEO.

Never having to use Oracle Database is a good result.

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

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

TDD is yet another in a long line of "methodologies" that don't work. Tests are not a bad thing of course. The problem comes when you turn testing into an ideology and try to use it as a magic fix for all your problems. Same goes for "agile," etc.

Programming is a craft. Good programmers write good code. Bad programmers write bad code. No methodology will make bad programmers write good code, but bureaucratic bullshit can and will prevent good programmers from working at their best. The only way to improve the output of a bad programmer is to mentor them and let them gain experience.

Post reply on HN