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…
Ask HN: What's the largest amount of bad code you have ever seen work?
451–460 of 601 posts
Re: Ask HN: What's the largest amount of bad code you have ever seen work?
#452Re: Ask HN: What's the largest amount of bad code you have ever seen work?
#453Oracle 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.
Re: Ask HN: What's the largest amount of bad code you have ever seen work?
#454Earlier 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…
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?
#455Earlier 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…
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?
#456Earlier 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…
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?
#457I 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…
Re: Ask HN: What's the largest amount of bad code you have ever seen work?
#458Earlier 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.
Re: Ask HN: What's the largest amount of bad code you have ever seen work?
#459Oracle 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.
Re: Ask HN: What's the largest amount of bad code you have ever seen work?
#460Earlier 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…
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.