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

Throwing away 18 months of code and starting over

tompiagg.io

Post reply on HN
Print view View original

51–60 of 89 posts

Re: Throwing away 18 months of code and starting over

#51

Post by shimman »

didgeoridoo wrote: post #45
ralferoo wrote: post #30

Earlier quoted context omitted.

Oh wow, it's from Mythical Man Month? I've been meaning to read that for years and still never have.

That and Brooks’ underrated “The Design of Design” are notable for having an almost impossible density of quotable aphorisms on every page. They’re all so relevant today that it’s hard to believe that he’s talking about problems he faced half a century ago.

Never heard of "The Design of Design" but I bought it off this comment chain.

I think our industry would do a lot to take a moment and breath to understand what we have collectively done since inception. Wonder often if we will look at the highly corporatized influence our industry has had during our time as the dark ages 1000s of years into the future. The idea that private enterprise should shape the direction of our industry is deeply problematic, there needs to be public option and I doubt many devs would disagree.

Re: Throwing away 18 months of code and starting over

#52

Post by simonw »

Hamuko wrote: post #44
simonw wrote: post #36

"For the longest time, I would NOT allow people to write tests because I thought that culturally, we need to have a culture of shipping fast" Tests are how you ship fast. If you have good tests in place you can ship a new feature without fear that it will break some other feature that you haven't manually tested yet.

I think the more specific description would be that "not writing tests allows shipping fast today, writing tests allows shipping fast tomorrow and afterwards". It wasn't too long ago that I wrote tests for something that was shipped years ago without any automated tests. Figured it was easier doing that than hoping we won't break it.

Yeah, but in my experience it really is a literal today vs tomorrow thing.

Your tests pay for themselves the moment you want to ship a second feature without fear of breaking the first.

Re: Throwing away 18 months of code and starting over

#53

Post by mattmanser »

abraxas wrote: post #9
ramesh31 wrote: post #4

Next 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…

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.

Re: Throwing away 18 months of code and starting over

#54

Post by pastescreenshot »

simonw wrote: post #36

"For the longest time, I would NOT allow people to write tests because I thought that culturally, we need to have a culture of shipping fast" Tests are how you ship fast. If you have good tests in place you can ship a new feature without fear that it will break some other feature that you haven't manually tested yet.

The rewrite version of this that has gone best for me is to do it as a strangler, not a reset. Pick one ugly workflow, lock in current behavior with characterization tests, rebuild that slice behind a flag, repeat. You still get to fix the architecture, but you do not throw away years of weird production knowledge.

Re: Throwing away 18 months of code and starting over

#55

Post by elAhmo »

I 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.

Re: Throwing away 18 months of code and starting over

#56

Post by hinkley »

oraphalous wrote: post #50
hinkley wrote: post #43

Earlier quoted context omitted.

> After we started hiring, it became a disaster. When it stopped being two people he still forbade tests. In this decade. That is fucking nuts. Fun fact: the guy I worked a 2 man project with and I had a rock solid build cycle, and when we got cancelled to put more wood behind fewer arrows, he and I built the entire CI pipeline. On cruisecontrol. And if you don’t know what that is, that is Stone Age CI. Literal stick…

Did anyone here actually look at the product they were actually building? It's an AI agent bug discovery product. Their whole culture is probably driven at a fundamental philosophical level about the problems of bug discovery. As he says: he wanted to rely on dogfooding - using their product as the way of spotting bugs. That may have been spectactular naivete but it's not insanity. The point I keep coming back to her…

What ends up happening is that your most fundamental features end up rotting because manual testing has biases. Chief among them is probably Recency Bias. It is in fact super easy to break a launch feature if it’s not gating any of the features you’re working on now. If you don’t automate those, yes, you’re nuts.

One of the worst ones I ever encountered was learning that someone broke the entire help system three months prior, and nobody noticed. Because developers don’t use the help system. I convinced a team of very skeptical people that E2E testing the help docs was a higher priority than automating testing of the authentication because every developer used that eight times a day or more. In fact on a previous project with trunk based builds, both times I broke login someone came to tell me so before the build finished.

Debugging is about doing cheap tests first to prune the problem space, and slower tests until you find the culprit. Testing often forgets that and will run expensive tests before fast ones. Particularly in the ice cream cone.

In short, if you declare an epic done with zero automation, you’re a fucking idiot.

Re: Throwing away 18 months of code and starting over

#57

Post by oraphalous »

maplant wrote: post #49
oraphalous wrote: post #40

Earlier quoted context omitted.

>He did not edit He edited his reply to me multiple times... which is what made me suspect an edit to the original comment. But whatever, I'm happy to acknowledge his original intent even if he did state it more harshly. >What we really don't need is paragraphs of someone arguing because their own definitions differ slightly from the OP This is unnecessary. OP came out with "AUTHOR IS INSANE" even on the most generou…

> He edited his reply to me multiple times... I got the sense from your reply that some extra clarity would be beneficial. > This is unnecessary. OP came out with "AUTHOR IS INSANE" even on the most generous of interpretations. I did not actually call the author insane, I called their decision to explicitly disallow testing insane. It's an insane decision. I am not _literally_ calling the author insane.

> I did not actually call the author insane...

If you think this distinction really matters wrt the point I'm trying to make, then it's time for you and I to bug out conversationally. Sometimes two individuals have such different ways of communicating that the pain of exegesis isn't worth the squeeze. No hard feelings. I'm sure 50% responsibility is at least mine, but it's not going to be worth it for either of us figuring out exactly what.

Re: Throwing away 18 months of code and starting over

#58

Post by [deleted] »

oraphalous wrote: post #57
maplant wrote: post #49

Earlier quoted context omitted.

> He edited his reply to me multiple times... I got the sense from your reply that some extra clarity would be beneficial. > This is unnecessary. OP came out with "AUTHOR IS INSANE" even on the most generous of interpretations. I did not actually call the author insane, I called their decision to explicitly disallow testing insane. It's an insane decision. I am not _literally_ calling the author insane.

> I did not actually call the author insane... If you think this distinction really matters wrt the point I'm trying to make, then it's time for you and I to bug out conversationally. Sometimes two individuals have such different ways of communicating that the pain of exegesis isn't worth the squeeze. No hard feelings. I'm sure 50% responsibility is at least mine, but it's not going to be worth it for either of us fi…

[deleted]

Re: Throwing away 18 months of code and starting over

#59

Post by maplant »

oraphalous wrote: post #57
maplant wrote: post #49

Earlier quoted context omitted.

> He edited his reply to me multiple times... I got the sense from your reply that some extra clarity would be beneficial. > This is unnecessary. OP came out with "AUTHOR IS INSANE" even on the most generous of interpretations. I did not actually call the author insane, I called their decision to explicitly disallow testing insane. It's an insane decision. I am not _literally_ calling the author insane.

> I did not actually call the author insane... If you think this distinction really matters wrt the point I'm trying to make, then it's time for you and I to bug out conversationally. Sometimes two individuals have such different ways of communicating that the pain of exegesis isn't worth the squeeze. No hard feelings. I'm sure 50% responsibility is at least mine, but it's not going to be worth it for either of us fi…

I'm not really arguing with your point, I'm correcting your incorrect description of what I'm saying.

To argue with your actual point: I don't really care about the overall context, actively disallowing tests in a codebase is a _bad decision_. Look how it worked out for them.

> it's time for you and I to bug out conversationally

Fine with me

Re: Throwing away 18 months of code and starting over

#60

Post by oraphalous »

hinkley wrote: post #56
oraphalous wrote: post #50

Earlier quoted context omitted.

Did anyone here actually look at the product they were actually building? It's an AI agent bug discovery product. Their whole culture is probably driven at a fundamental philosophical level about the problems of bug discovery. As he says: he wanted to rely on dogfooding - using their product as the way of spotting bugs. That may have been spectactular naivete but it's not insanity. The point I keep coming back to her…

What ends up happening is that your most fundamental features end up rotting because manual testing has biases. Chief among them is probably Recency Bias. It is in fact super easy to break a launch feature if it’s not gating any of the features you’re working on now. If you don’t automate those, yes, you’re nuts. One of the worst ones I ever encountered was learning that someone broke the entire help system three mon…

I think maybe - this conversation is more about giving some more acknowledgement to the other side of this issue.

It's not that I disagree with you essentially - or particularly with respect to your analysis of your specific examples. 100% in the cases you describe. Those sound like beneficial tests. Particularly because your example SPEAKS to the business case - users were using the help docs (I think you mean users anyway). So yeah - that's important.

But I don't know why it's so hard extracting a simple acknowledgement of what I'm pointing out - specifically that the decisions like implementing tests IS a cost-benefit decision dependent on business context.

Funny you mention auth testing though. One time both me and the tech lead broke one of the auth flows in production within the space of a week of one another. Yep - no tests. Feel free to judge us insane. But here's how we thought about it - and when I say "we" that includes the business. First of all the auth flow was not actually used by any active users, so damage was low. Two man dev team. Complexity up until that point had been low, pre-product market fit, sales were dogshit, and cash had been low for some time. Feature shipping was the 110% priority. Ok - but these bugs were a sign complexity had increased beyond what we could manage without some tests. And given the importance of auth, it was now easy to make the case to leadership that implementing an e2e test suite was worth it. So we did.

If you still think a decision making process like that is insane - because we didn't immediately implement tests for every shipped feature. Well - I just think you're wrong.

Post reply on HN