Just keep coding
-
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.
-
This post did not contain any content.wrote last edited by [email protected]
I've seen worse. There are no big holes in the wall.
-
You can’t really look at the ones that didn’t hold.
Excellent point. For those who are unfamiliar: Survivorship bias
-
You can’t really look at the ones that didn’t hold.
-
"Look, guys, I vibecoded a wall!"
wrote last edited by [email protected]"It goes almost all the way to the ceiling. I just need you to connect the last layer into the structure, it should be a 15 minutes work, right? I already settled the deadline with your boss. Tanks; bye."
-
I've seen worse. There are no big holes in the wall.
this plan called for windows gothy
-
This post did not contain any content.
Geez, it's like coders are only happy when bashing other people's codes...
What do coders say when they're tasked with continuing some other coder's task? "This is all wrong".
-
Geez, it's like coders are only happy when bashing other people's codes...
What do coders say when they're tasked with continuing some other coder's task? "This is all wrong".
That's also what we say when continuing our own task
-
This post did not contain any content.
I'm not gonna lie, I like how that wall looks lol.
-
That's also what we say when continuing our own task
I've rewritten much of my code as needs changed, I call myself an idiot a lot since I've worked on this program nearly a decade and was my first professional software so often change old code I wrote. Though it was more additional at first since I used a lot of code the lead programmer did. Though he duplicated everything as needed for a tiny change ugh. Least I know how not to do it.
-
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
wrote last edited by [email protected]no one has a budget for that
your whole team is fired, we got ‘Bob’ from India handling this now
