Just keep coding
-
Your options are an ugly wall that works or the beautiful lack of a wall.
Sure, though having gone through an entire monorepo refactoring of like half a million lines to basically destroy the codebase and switch from vue 2 to vue 3 among other things, it’s also possible to build the new, better designed wall right behind the old one, test like hell against that wall, and then shift that wall in when it’s ready in a planned release, ready for the issues that come because that wall isn’t quite like the old wall
-
I mean, when you look at old walls made of quarry stone, they kinda look like this and still hold.
You can’t really look at the ones that didn’t hold.
-
Well that's not true. I live in a Soviet era house that had an entire second floor built on top of it. We've had to drill through the brick walls to replace the natural gas pipes with pipes that run outside the walls, we've had to dig under the foundation when we got connected to the city's sewer system (again, Soviet-built), and again when the main water pipe burst and threatened to wash out the foundation. If the load-bearing walls had been constructed to the same "it works" standard as the things we've had to fix, we wouldn't have a house anymore.
Agreeing with you, just adding to it.
The same thing happens to any old house, not only soviet ones.
In my city most houses are close to 200 years old. That's well before plumbing going into every flat, well before electricity and well before any of the other cool stuff like central heating, internet and so on.
Most of these houses don't even retain the original apartment layout.
Houses are living things that see a lot of change when they get old enough.
-
This post did not contain any content.
"Look, guys, I vibecoded a wall!"
-
Also brick walls don't really go through iterative changes, which is an important issue with tech debt.
If the wall works, then it works
A software project will work now, but may not hold up when you need to change something
wrote last edited by [email protected]You don't ever HAVE to update software though. That's just the way it's usually done now. It's a choice. Usually updates are made to add more features or monetization or whatever but you could just not do that.
If you look at old video games for example those were released and never updated again. They will still work today too.
-
This post did not contain any content.
Me when Claude code writes bullshit I don't need
-
You don't ever HAVE to update software though. That's just the way it's usually done now. It's a choice. Usually updates are made to add more features or monetization or whatever but you could just not do that.
If you look at old video games for example those were released and never updated again. They will still work today too.
add more features or monetization or whatever
That "whatever" is doing a lot of work.
Security patches and bug fixes are arguably the most important reason to update.
-
This post did not contain any content.
"Waterfall? Won't the water break our computers?"
-
Sure, though having gone through an entire monorepo refactoring of like half a million lines to basically destroy the codebase and switch from vue 2 to vue 3 among other things, it’s also possible to build the new, better designed wall right behind the old one, test like hell against that wall, and then shift that wall in when it’s ready in a planned release, ready for the issues that come because that wall isn’t quite like the old wall
This is a dangerous metaphor. Remove the old wall and it turns out the new beautiful wall was leaning against and supported by it.
I get what you mean, it’s just that the metaphor could support both perspectives.
-
You don't ever HAVE to update software though. That's just the way it's usually done now. It's a choice. Usually updates are made to add more features or monetization or whatever but you could just not do that.
If you look at old video games for example those were released and never updated again. They will still work today too.
If your a business and the majority of your business customers updates from win 11 to win 12 than you have to update to support win 12 to, to keep the revenue stream running.
-
This is a dangerous metaphor. Remove the old wall and it turns out the new beautiful wall was leaning against and supported by it.
I get what you mean, it’s just that the metaphor could support both perspectives.
Build the new wall airgapped from the old one
-
Build the new wall airgapped from the old one
And keep both walls for redundancy.
-
You can’t really look at the ones that didn’t hold.
wrote last edited by [email protected]Developer, smacking wall: "This bad boy ain't going nowhere"
User base, rolling up their trebuchets:
-
Also brick walls don't really go through iterative changes, which is an important issue with tech debt.
If the wall works, then it works
A software project will work now, but may not hold up when you need to change something
My wall keeps crashing and I don't know why.
-
If your a business and the majority of your business customers updates from win 11 to win 12 than you have to update to support win 12 to, to keep the revenue stream running.
We updated the roads, your old car won't work on these.
-
I mean, when you look at old walls made of quarry stone, they kinda look like this and still hold.
My thought as well, but those stones were shaped to match each other, reducing the amount of grout needed. It just goes to show the old ways still work, but you have to commit.
-
Also brick walls don't really go through iterative changes, which is an important issue with tech debt.
If the wall works, then it works
A software project will work now, but may not hold up when you need to change something
Uhm...
-
Your options are an ugly wall that works or the beautiful lack of a wall.
wrote last edited by [email protected]* For a very specific value of "works". Offer is limited in time. No refunds. Warranty doesn't cover damage caused by the elements, presence, or lack of gravity. Other conditions may apply.
-
Sure, though having gone through an entire monorepo refactoring of like half a million lines to basically destroy the codebase and switch from vue 2 to vue 3 among other things, it’s also possible to build the new, better designed wall right behind the old one, test like hell against that wall, and then shift that wall in when it’s ready in a planned release, ready for the issues that come because that wall isn’t quite like the old wall
Making the new wall is not a money generator. You would be insane if you think suits would waste money to rebuild something when it generated minimal to no additional revenue.
-
Making the new wall is not a money generator. You would be insane if you think suits would waste money to rebuild something when it generated minimal to no additional revenue.
True, I'm lucky to work for a company that was half founded by engineers who know the cost of compounding technical debt, which is almost never the case.
