Astro Hacker News - Throwing away 18 months of code and starting over

ralferoo |next [-]

It's not really hinted at in the article, which doesn't actually mention whether the rewrite was a net gain - I presume it was or they wouldn't have written the article, and the lead-in picture paints a rosy picture, but the tone at the end suggests he's not happy with how things turned out.

But one thing that used to be a common design anti-pattern was the "version 2 problem". I think I first heard about it when Netscape were talking about how NN2 was a disaster, and they were finally happy with NN3 or NN4.

Often version 1 is a hastily thrown together mess of stuff, but it works and people like it. But there's lots of bad design decisions and you reach a limit with how far you can continue pushing that bad design before it gets too brittle to change. So you start on version 2, a complete rewrite to fix all the problems and you end up with something that's "technically perfect" but so overengineered, it's slow and everybody hates it, plus there are probably lots of workflow hoops to jump through to get things approved that you end up not making any progress, and possibly version 2 kills the product and/or the company.

The idea is that the "version 3" is a pragmatic compromise - the worse design problems from version 1 are gone, but you forego all the unnecessary stuff that you added in version 2, and finally have a product that customers like again (assuming you can convince them to come back and try v3 out) and you can build into future versions.

To a large degree I think this "version 2 problem" was a by product of waterfall design, it's certainly been less common since agile development became popular in the early 2000s and tooling made large scale refactoring easier, but even so I remember working somewhere with a v1 that the customers were using and a v2 that was a 3-year rewrite going on in parallel. None of the developers wanted to work on v1 even though that's what brought in the revenue, and v2 didn't have any of the benefit of the bug fixes accumulated over the years to fix very specific issues that were never captured in any of the scope documents.

pjmorris |root |parent |next [-]

"The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a "big pile."

- Fred Brooks, 'The Mythical Man Month' (1975)

basket_horse |root |parent |previous [-]

This has been my experience exactly. V1 was custom built for a single client and they loved it. As we tried to expand to multiple clients the v1 was too narrowly scoped (both in UX and code architecture) so we did a full rewrite attempting to generalize the app across more workflows. V2 definitely expanded our client pool, but all our large v1 customers absolutely hated it.

We never did a full v3 rewrite, but it took about 4 years and many v3 redesigns of various features to get our legacy customers on board.

maplant |next |previous [-]

Having 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

oraphalous |root |parent [-]

I think your comment is just as "insane" as the practice you are railing against. Although I wouldn't use the word "insane" - it's hyperbole. What's the right word here? I'm not sure... "dogmatic" isn't quite right.

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 I find "insane", "dogmatic"... about your comment is the complete elision of this process of cost-benefit analysis, as if there should never be such an analysis.

I've worked with a lot of people like you. When a discussion begins about a choice to be made, they just stampede in with "THIS IS THE RIGHT WAY". And the discussion can't even be had.

This sort of "dogmatism" is so rife if engineering culture, I wonder if this is why the c-suite is so ready to dump us all for AI centaurs that just fucking ship features. How many of them got burned listening to engineers who refused to perform even the most basic of cost benefit analyses with the perspective of the business as a whole in mind and forced the most unnecessary, over-engineered bullshit.

I worked at one startup where the tech lead browbeat the founders into building this enormous microservice monster that took them years. They had ONE dev team, ONE customer, and the only feature actually being used was just a single form (which was built so badly it took seconds to type a single character in a field cause the React re-renders were crazy).

Now THAT's insanity.

soperj |root |parent |next [-]

> they just stampede in with "THIS IS THE RIGHT WAY". And the discussion can't even be had.

That's exactly what this person is railing against. They strictly forbid testing.

sodapopcan |root |parent |next |previous [-]

The truth is in the middle somewhere, regarding tests at least (yes, your microservices story is insane).

I think the author could have been happier with the no-test decision if they had treated the initial work as a prototype with the idea of throwing it away.

At the same time, writing some tests, should not be seen as a waste of time since if you're even at all experienced with it, it's going to be faster than constantly reloading your browser or pressing up-up-up-up-up in a REPL to check progress (if you're doing the latter you are essentially doing a form of sorta reverse TDD).

So I dunno... I may be more in line with the idea that's a bit insane to prevent people from writing tests BUT so many people are so bad at writing tests that ya, for a go-gettem start up it could be the right call.

I certainly agree with your whole cost-benefit analysis paragraph.

maplant |root |parent |next |previous [-]

Did I say that my way was the right way? No: what I said was actively disallowing tests in every situation was the wrong way.

There is no ability here for the cost benefit analysis to change over time. There is only no tests

oraphalous |root |parent [-]

Did you edit the wording of your original comment slightly to emphasise the "actively disallowing them" in every situation? Anyway... if that is what you meant, then ok. It's less awful a statement than what I felt I originally read.

I'd still push back on your hyperbole though. I don't think the author was insane - and we don't know what the broader business context was when they started growing the team and decided to persist without building out the test architecture at that point. They made a call that dogfooding was going to be enough to catch issues as they grew the team. There are a lot of scenarios where that is going to be true.

One scenario where it wouldn't - the most likely - is that the team isn't actually dogfooding because they personally don't find the product useful. Leadership lambasts them to use the product more... but no one does cause it sucks so much it impacts their own personal productivity.

Even there I wouldn't use the word insane... just poor leadership.

maplant |root |parent [-]

> Did you edit the wording of your original comment slightly to emphasise the "actively disallowing them" in every situation?

I did not.

UltraSane |root |parent |previous [-]

Not having ANY tests means tons of manual testing is needed every time you modify code, which will rapidly consume more time than writing the tests would.

fabiensanglard |next |previous [-]

Pearls.

> I would NOT allow people to write tests

> now [...] we started with tests from the ground up

Trufa |root |parent [-]

Two different stages of the project, not necessarily contradictory. I'm not saying this is great, but tests make a whole lot more sense when you know what you're building.

sodapopcan |root |parent [-]

Yes. TFA author could have gone into it with this mindset and treated the initial work as a prototype with the idea of throwing it away and would have been happier about it.

> but tests make a whole lot more sense when you know what you're building.

It's very true. This is a "gotcha" a lot of anti-TDDers always bring up, and yet some talk about "prototyping == good" without ever making the connection that you can do both.

4rtem |next |previous [-]

Nice using of the io domain there

renewiltord |next |previous [-]

Tests are most useful for regression detection, so it's a good instinct to not add them when you're primarily exploring. Once you've decided to switch to exploitation, though, regression will hurt. I think it's just a classic 0 to 0.1 not being the same thing as 0.1 to 1.

heliumtera |next |previous [-]

So you started with 2023 theo.gg philosophy but now moved on to 2026 theo.gg philosophy

andrewstuart |next |previous [-]

I wouldn’t admit to this level of frankly incompetence.

Wildly swinging dogmatism on how to do software development that’s so wrong you have to throw it all away - then repeating this failure loop multiple times.

Doesn’t inspire any confidence in the person I wouldn’t get them to lead a project.

Why would you be so loud and proud about all this.

randlet |root |parent |next [-]

"bugs were appearing everywhere out of the blue. The codebase was a huge mess of nulls, undefined behaviour, bad error handling. It was so bad that we actually lost a client over this."

Especially wild considering their product is literally an automated bug finder lol.

monsieurbanana |root |parent |previous [-]

I think there's a real possibility this is a "no such thing as bad publicity" stunt.

ramesh31 |next |previous [-]

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.

abraxas |root |parent [-]

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 to explore in software engineering. Ruby and nodejs weren't it.

sgarman |root |parent [-]

Mongodb is webscale.

steve_adams_86 |root |parent [-]

Do you think it can handle 10 requests per hour? How many mongo instances will that require, and should I use micro services?