https://news.ycombinator.com/item?id=47317568 - A submission by this person's company where they say they'll refund you if a bug makes it past their system. Given how buggy their own system apparently is (to the point they're scrapping all the code), perhaps it's not such a smart offer on their part.
Throwing away 18 months of code and starting over
71–80 of 89 posts
Re: Throwing away 18 months of code and starting over
#72I can't imagine working as a developer at a place where manager/founder "does NOT allow" tests to be written. This, combined with four pivots mentioned in the article seems like they are just riding the hype and trying to brute-force a product without having any basics or PMF.
How companies like this get funding is well beyond me.
Re: Throwing away 18 months of code and starting over
#73Earlier quoted context omitted.
There is supposedly a famous video series of Uncle Bob trying and failing to solve sudoku with TDD. He did not read any guides on solving it and tried from first principles instead, and bounced off of it. It’s clear to me that if you don’t know what you’re building, testing it first has rubber duck value that can easily be overshadowed by Sunk Cost. I always test my pillars - the bits of the problem that are definite…
Not Bob Martin, sudoku with TDD was Ron Jeffries. https://news.ycombinator.com/item?id=3033446 - Linking to this old comment because it links to each of Ron's articles, a discussion about it, and Norvig's version.
Hah! That's probably why I can never find it.
Norvig's solution is a work of art. When people ask me for examples of intrinsic versus accidental complexity, his sudoku solver is the best one I have. My only note is that he gives up and goes brute force early. When I first encountered it I had a lot of fun layering other common solving strategies on top of his base without too much extra trouble.
What I did not have fun with is porting it to elixir. That was a long journey to get to a solution I could keep adding stuff too. Immutable data is rough, particularly when you're maintaining 4 distinct views on the same data.
Re: Throwing away 18 months of code and starting over
#74Earlier quoted context omitted.
There is supposedly a famous video series of Uncle Bob trying and failing to solve sudoku with TDD. He did not read any guides on solving it and tried from first principles instead, and bounced off of it. It’s clear to me that if you don’t know what you’re building, testing it first has rubber duck value that can easily be overshadowed by Sunk Cost. I always test my pillars - the bits of the problem that are definite…
> Yes, starting with tests without market fit can also be fatal. But calling anything done without tests is just a slower poison. I think we are pretty close to agreement here. I'd be interested in what you have experienced in the realm of front-end testing though - whether you think things are just as cut and dried in that realm (that's another discussion though). And I'll also accept the point about skill in test w…
Testing is hard. No, testing is fucking hard. I've had more mentors in testing than any other two disciplines combined. And I still look at my own tests and make faces. But to a man everyone who has claimed testing is not hard has written tests that made me want to push them into traffic.
Every problem is easy if you oversimplify it.
I send people who come to me struggling with their tests away with permission to fail at them but not permission to give up on getting better. You're gonna write broken tests. Just don't keep writing the same broken tests.
If anyone looking for a PhD or book idea is reading along with this, my suspicion is that it's so difficult because we are either 1) fundamentally doing it wrong (in which case there's room for at least 2 more revolutions in testing method) 2) someone will prove mathematically that it's an intractable problem, Gödel-style, and then someone will apply SAT solvers or similar to the problem and call it a day. Property based testing already pretty much does Monte Carlo simulation...
For backend tests, the penalty at each level of the testing pyramid is about 8x cost for a single test (and IME, moving a test down one level takes 5x as many tests for equivalent coverage, so moving a test down 2 layers reduces the CPUtime by half but also allows parallel execution).
For frontend I think that cost is closer to 10x. So you want to push hard as you can to do component testing and extract a Functional Core for unit tests even harder than you do for backend code. Karma is not awesome but is loads better than Selenium, particularly once you have to debug a failing test. I've been on long projects for a minute so I can't really opine on Puppeteer, but Selenium is hot flaky garbage. I wouldn't tolerate more than 100 E2E tests in it, even on a half million line project. Basically a smoke test situation if you use it like that, but you won't have constant red builds on the same eight tests on shuffle.
I want to say we had 47 E2E tests on a project I thought was going swimmingly from a SDLC perspective. But it might have been 65.
Re: Throwing away 18 months of code and starting over
#75Earlier quoted context omitted.
> Yes, starting with tests without market fit can also be fatal. But calling anything done without tests is just a slower poison. I think we are pretty close to agreement here. I'd be interested in what you have experienced in the realm of front-end testing though - whether you think things are just as cut and dried in that realm (that's another discussion though). And I'll also accept the point about skill in test w…
Testing is hard. No, testing is fucking hard. I've had more mentors in testing than any other two disciplines combined. And I still look at my own tests and make faces. But to a man everyone who has claimed testing is not hard has written tests that made me want to push them into traffic. Every problem is easy if you oversimplify it. I send people who come to me struggling with their tests away with permission to fai…
Great comment... and I feel after reading it, you're probably a pretty great person to work with. Acknowledging the pain / difficulty of a task, but inspiring folks, and giving them the opportunity to perservere is rare to find these days.
Re: Throwing away 18 months of code and starting over
#76Having a culture of not ever writing tests and actively disallowing them is so insane I can't even imagine why there's anything else in this post
[flagged]
> If you are a two man startup, burning through runway and pre-product-market fit... then spending a lot of time on tests is questionable (although the cost-benefit now with AI is changing very fast).
What's insane that people in 2026 still think tests slow you down.
It takes me maybe 40 hours (1 week) of coding to start receiving ROI from writing tests in a greenfield project, and by 80 hours I'm pretty sure I've saved more time from bugs and improved design due to TDD than I've spent writing the tests.
The ROI is even faster if I'm not the only developer on the project.
If your flagship product takes less time to develop than 40 hours, then your product is extremely vulnerable to being copied by another company, so your entire software project is a bad business idea.
So there really aren't many exceptions: either your project benefits from tests, or it's too easy a project to be a business.
So frankly, it's your comment lacking in cost/benefit analysis.
Re: Throwing away 18 months of code and starting over
#77Earlier quoted context omitted.
Okay, yes, that's a hard disagree. I have an education and experience in software development. If a manager told me to make a product in an unsafe manner, I'd refuse, and if push came to shove, leave. Leave, both because I wouldn't be able to defend my work as a professional, but also because I wouldn't work under someone who would want to dictate the manner in which I do what I do.
This is missing the point. If you’re a 2 man team it’s much more important to have code that has a couple bugs in it but allows you to quickly find your product market fit. As opposed to perfect code with no bugs that is useless. No one is disagreeing that tests are good in a vacuum / mature product. But if your focus is building a mvp, and you’re trading off the test time with other things, it’s not always worth it.…
[deleted]
Re: Throwing away 18 months of code and starting over
#78You sound like an absolute nightmare to work for.
Re: Throwing away 18 months of code and starting over
#79Earlier quoted context omitted.
Which in turn were only invented because millennials would not be caught dead writing Java and JSP. We had all this shit figured out by the late nineties and 90% of what is accomplished on the web today was entirely possible and well integrated in Java app servers. This whole business is a fashion industry. I'm for one grateful for LLMs because for the first time in around 30 years there is actually genuine novelty t…
It really wasn't. MVC really changed web dev for the better, and Django/Rails trail-blazed it. It's one of the few paradigms I've seen in my career that was an unequivocal win for us.
We were already doing MVC in products like the one sold by Altitude Software in Portugal, in a Tcl based platform that was inspired on Vignette and AOLServer.
The authors of said product eventually went on to create OutSystems, one of the very few RAD products to do Delphi/VB like application servers with graphical tooling.
It was no need for Django/Rails trail-blaze anything other than not everyone has Silicon Valey visibilty to push their ideas.
Re: Throwing away 18 months of code and starting over
#80Next is such a dumpster fire. So much wasted effort due to the Node ecosystem never developing a universal batteries included framework like Rails or Django.
Which in turn were only invented because millennials would not be caught dead writing Java and JSP. We had all this shit figured out by the late nineties and 90% of what is accomplished on the web today was entirely possible and well integrated in Java app servers. This whole business is a fashion industry. I'm for one grateful for LLMs because for the first time in around 30 years there is actually genuine novelty t…
Indeed, as someone confortably on Java/.NET ecosystem, I only put up with stuff like Next.js, because it has become a required skill in the headless SaaS products space.
Thanks to Vercel partnerships, many of those SaaS vendors only support Next.js as extension/integration technology on their SDKs.