Hacker News new | ask | show | jobs
by nabla9 1910 days ago
“Continuous integration and testing practices" are useless when you are going to rewrite the software from ground up every year or two years. You just patch the software until it's time to throw it away.

Many startups write something that they can sell, get experience, realize what they should have been doing instead, then do that.

2 comments

Your team’s velocity will be faster from week 2 through the end of the 2nd year if you build the rapid feedback cycles provided by automated testing and CI/CD into your progress from the beginning

UNLESS your team lacks the experience to build and maintain a test suite with a high benefit-to-cost ratio, which is unfortunately the case for most teams.

In this case I don’t have any good solutions, other than choosing one’s team and teammates carefully, before starting the project.

“Continuous integration and testing practices" are not exactly a great burden, and you don't know when the thing you are working on is going to snowball and become the thing you need to nurture and grow. Even if you pivot, you will likely want to re-use code written for earlier attempts.

I suspect the reason startups don't do the bare minimum here is because their developers tend to be cheaper and less experienced (at least until they get funding), and "we move fast and break things" is just a lame justification for incompetence.

Actually you are more likely to rewrite and migrate away from that legacy codebase once you succeed/pivot

I recommend watching Kent Back’s 3X talk for that, I also wrote a blogpost about it: https://rchavesferna.medium.com/designed-v-evolutionary-code...

In theory yes, you're supposed to migrate away from the legacy codebase.

In practice I've never, ever, ever seen that happen: it's too much upfront cost to start over, especially when you have real customers and real data on top of it and you need to keep pumping out new features.

It's not that. For a startup figuring out what the product is and making it happens in parallel.

Product and product research are the same.