Hacker News Reader

Comment by stoicShell | Hacker News Reader

The saying only applies when your product is software itself, not in most cases where software is just the means to deliver your product — here a website providing education in video form etc.

Besides, the reality is that most business software out there gets rewritten every 3-15 years (really depends on use-case and conditions, but on average 4-5-6 years is a good bet). After some time it's just not worth it to keep refactoring, you'd rather start anew with hopefully better tech and certainly with better knowledge of your problem — they say you should write everything 3 times to make sure you really nailed it.

In many businesses, these rewrites would constitute a new major version, more comparable to the feeling we always got in the waterfall era — new version = big changes, new UI, new stuff. That's when it's possibly lethal, if you really break the thing, and that thing is your product, not a means to it.

View on HN

the number of failed migrations, modernizations, and "tech transformations" in non-software industries, as well as the number of consulting outfits and their profits doesn't seem to back this up.

[0] IT disasters now part of modern life - https://www.afr.com/technology/it-disasters-now-part-of-mode...

[1] Number of IT failures at banks and other firms is unacceptable, say MPs - https://www.theguardian.com/business/2019/oct/28/number-of-i...

[2] The Biggest IT Failures of 2018 - https://spectrum.ieee.org/riskfactor/computing/it/it-failure...

we can argue whether these are "rewrites", but big changes can be rewarding but are inherently risky. balancing this is hard, and rewrites uncover and introduce the unknown unknowns.

That will make for some pretty salient readings, thanks for the links.

There are obviously cases of failure. I don't know the stats. I'm speaking mostly of small/medium businesses, where size and complexity are different.

that's fair, most of those are "you get what you pay for" and hardly the fault of a competent, well-meaning, but naive dev team. problem is it's much harder to get data on small businesses.

i think one thing we can agree on is that the only thing users hate more than change is breakage.

rewrites are a valid tool in a long-term strategy, just as debt is for finance. but for most people, incremental change has a bigger, smoother RoI. it sounds like this is kind of what KA is doing. although the timeline seems aggressive and the whole thing absolutist, being stuck on Python 2 is a risk now, too.

I think we agree on the general perspective, yes — we'd probably agree as a team with known (ad hoc) conditions and goals.

Data on small businesses is hard indeed. I'm only speaking anecdotally from the MSP / software shops perspective, the "tech guys" of most businesses who don't in-house IT. Also from a European perspective, so that might make a big difference — we're, ahem, let's say not as involved, interested, or capable in all things "technology" as a general population (I didn't say luddites but that's how it feels sometimes, compared to the vibe I get in NYC or rich Asian cities).

Reply on news.ycombinator.com