Re:Humble Bundle just killed most of their security through ...
by berkes on Thursday November 12, 2026 @05:07AM
(#50465213)
> rewrite is functionally worse for users
I've been involved in many "rewrites". Almost exclusively, the result is worse for users at release.
Especially with "big bang releases". Where a team is working behind the scenes for months or longer, attempting to rewrite the old system "bug for bug". Releasing and then finding out that some users would "hold the space bar to make the CPU heat up, and configuring emacs to interpret that as 'control'" (XKCD 1172). First, users don't see any improvements for all the time that the new system was being built. Secondly, they get all the new stuff bundled. So while they may even get value from the rewrite, it is bundled with the stuff that makes it worse. Three new features, one new bug. And all everyone sees is that new bug.
But even rewrites where parts are swapped out and released immediately, (strangler vine pattern!) are worse for the users. They do get value fast. And in small increments. They can give feedback early. But the (much longer) period in which the replacements are implemented, is almost always one of confusion, complexity, and "having to learn new things every week". We all know the systems where "change email" is a link that leads to a form on some other site, in an old design rather than part of the "edit account" page. Because the "account service" has been extracted, but the "notification service" replacement on the backlog still.
"rewrites" are almost always for the benefit of the business, the technical team, or other internal reasons. If "benefit to the users" is a part of it, it's almost always secondary: so that we can build and release and scale new features and cool stuff for users faster than with the old legacy spaghetti debt.
I've been involved in many "rewrites". Almost exclusively, the result is worse for users at release.
Especially with "big bang releases". Where a team is working behind the scenes for months or longer, attempting to rewrite the old system "bug for bug". Releasing and then finding out that some users would "hold the space bar to make the CPU heat up, and configuring emacs to interpret that as 'control'" (XKCD 1172). First, users don't see any improvements for all the time that the new system was being built. Secondly, they get all the new stuff bundled. So while they may even get value from the rewrite, it is bundled with the stuff that makes it worse. Three new features, one new bug. And all everyone sees is that new bug.
But even rewrites where parts are swapped out and released immediately, (strangler vine pattern!) are worse for the users. They do get value fast. And in small increments. They can give feedback early. But the (much longer) period in which the replacements are implemented, is almost always one of confusion, complexity, and "having to learn new things every week". We all know the systems where "change email" is a link that leads to a form on some other site, in an old design rather than part of the "edit account" page. Because the "account service" has been extracted, but the "notification service" replacement on the backlog still.
"rewrites" are almost always for the benefit of the business, the technical team, or other internal reasons. If "benefit to the users" is a part of it, it's almost always secondary: so that we can build and release and scale new features and cool stuff for users faster than with the old legacy spaghetti debt.