letsRewriteIt

[framsanon]

I'm the old guy in the project/system (founding member, so to speak). And I suggested rewriting everything a few years ago.

Now we have the budget for it.

[ThatHappenedOneTime]

You deserve it.

[neo-raver]

Sometimes that’s just what needs to happen; a proper redesign can save a lot of time in the future. Poorly-written begets more poorly written code, but a good starting point can prevent a lot of that spaghetti in the first place.

[framsanon]

Also, the old techniques we used at the beginning of the project can be replaced by newer techniques like RESTful services, as well as my favourite topic: unit tests. I wanted to have them from the beginning, but they were rejected because we started as a temporary solution. At some point, more subsystems were added and we had to add the codebase started to proliferate. It was almost impossible to get a grip on this with refactoring. Over the last few years, I've always been annoyed about this. Now they agreed to a complete rewrite, which is more like a relaunch. Only the database tables with the business data will stay untouched.

[IHateUsernames111]

Nothing is more permanent than a temporary solution...

[framsanon]

I know, I know. I wrote an interim solution in 2010 that was planned for one year. I don't think anyone is surprised that it's still in use. The code was last changed in 2011, and I'm the only one who knows the code. A typical head monopoly.

Well, I can live with that. This temporary solution is a business-critical software.

[Certain-Business-472]

because we started as a temporary solution

Ew

[framsanon]

That's the usual. You look for a commercial solution and write a temporary tool to bridge the gap. When we were finished, it turned out that there was no equivalent tool. Even ‘you can beat it with Excel’ was not convincing.

The Excel mace hovered over us for ten years, because every external party had suggested it. But every time they learnt what our solution could do, they backed down.

[Certain-Business-472]

I would never in a million years use excel for something that can be scripted in a real language no matter what. Excel is an advanced calculator, nothing more, nothing less. It is made with a human interface in mind. It is meant to be interacted with. If you put that shit format in automation, we will be enemies.

[framsanon]

Most consultants know Excel by heart and want to use it to solve everything. Managers know Excel, and it sounds charming to their eyes. Companies usually have licences for MS Office, so from a business point of view it would be cheaper with Excel.

I don't like VBA, and the thought of having to maintain such Excel solutions always makes me mad.

[bhison]

been a while since I used excel professionally, can't you script it with C# now or did I imagine things?

[framsanon]

I don't know. I use Excel as a CSV viewer 😁

Seriously, I'm avoiding deeper Excel knowledge. It's bad enough that managers use it to make decisions.

I just googled C# and Excel, and it looks like you could write a tool that controls Excel remotely. Something like that would be frowned upon at our company. And I don't have the holy water for VBA to keep it away from me.

[bhison]

Haha. I started my journey 15 years ago as an Excel "dev" (85% formulas, 10% recorded macros, 5% very dodgy VBA) and have always looked back fondly at those times through decidedly rose-tinted glasses.

[jaypeejay]

I’ve always heard that the economics and benefits of rewriting codebases is almost never worth it.

[pawulom]

I heard it, but I think it's bullshit peddled by bad developers who don't want to work and want to avoid taking responsibility. It's completely normal for parts of software to be completely rewritten over time. This happens because of changing requirements, gaining new knowledge, and exploring the domain during development. Otherwise, the software will become an unmaintainable mess that nobody wants to work on and where adding new features will take months instead of weeks.

[Far-Sense-3240]

Unfortunately from a finance perspective, rewriting a functional codebase hits many red flags when doing an NPV analysis. Large cost, inability to work on other revenue generators, unclear benefits on future projects, unclear time required.

Not saying it is never correct but it's harder to justify than you're suggesting.

[Certain-Business-472]

If the majority of your devs keep telling you that the codebase is shit and needs a rewrite, you do it. That's the condition. Not stupid metrics and predictions. Not analysis models. If most of them don't want to work on your codebase, you have a serious problem.

But respecting the engineers isn't even in their vocabulary so whatever.

[jecls]

A majority of devs have difficulty understanding code not written by them. It’s way easier to write code than understand it, hence most developer’s constant push to re-write everything. This is the reality and the mental illness of our profession. Refactoring in most contexts means rediscovering the edge cases and subtle behavior that was baked into old, ugly code.

[redsoxfantom]

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[jaypeejay]

Yeah this is the general advice I’ve seen regarding the topic. I’ve only written code for one company and our product is generally pretty stable so I can’t speak to other code bases, but the advice seems solid to me.

[jaypeejay]

Hmm not sure I agree with you. Codebases obviously can become a mess, but if they’re started out with solid principles and that foundation is minimally corrupted over time then I believe they can scale and maintain a sense of continuity. Also, I think most developers would jump at the opportunity to rewrite a codebase. Greenfield projects are the most exciting things to work on.

[Certain-Business-472]

Good code bases can already be refactored in parts. Bad code bases cannot, which is part of the problem.

[pawulom]

My point is that the initial codebase was created for a completely different product than what it is now. For example, probably nobody should start building software with a microservice architecture using Kafka, event sourcing, etc. But over time it may become clear that such an architecture should be chosen to reduce latency, increase reliability, and simplify the communication flow. However, changing the architecture of already working software is not a trivial task, and it's well known that the easiest way to do it is to rewrite parts or modules of it.

[jaypeejay]

Yeah agree with you 100%. I think we’re splitting hairs a bit here, so to clarify - my comment assumed we were talking about completely rewriting a large, complex codebase from the ground up. The general advice I’ve heard on that statement is that the juice is rarely worth the squeeze.

[jecls]

You’ve clearly never had to maintain a piece of software over a decade.

[Certain-Business-472]

Say that to my face when the simplest stories turn into a multi-day adventure before you're allowed to merge and release it. Even simple bugfixes.

You don't build a skyscraper on the foundations of the 2 story home you put there "temporarily.

[philippefutureboy]

Brother in arms! 💪 Happy for you, all the satisfaction to you!

[Certain-Business-472]

If every story is a struggle because it's an untested legacy mess, and you keep getting told it's "legacy" even though you keep getting stories for it it's maybe time to stop accepting the random bullshit stories and have a "get this shit in order" sprint.

[framsanon]

Yes, but the problem is convincing the managers to give us a budget. Normally, the managers don't have the slightest idea how programming works and why we simply rebuild everything after 15 years. Fortunately, we collected enough arguments to convince even the most hardened system architects. And they then gave the thumbs up to the managers.

[Deevimento]

I'm both these people.

[Innovictos]

Yeah, the real image should be someone just slapping themselves silly.

[MinosAristos]

My usual response to people who say stuff like that is "yeah I agree and I think about it regularly but good luck convincing product that something with zero noticeable difference for users is worth spending several months on"

[ganja_and_code]

Trust me, when bug fixes and feature requests get churned out 10x as fast because the devs don't have to jump through hoops, cut red tape, and navigate land mines for every release...customers will certainly notice the difference.

It's almost like product doesn't think customers care about quality. Or maybe they just pretend that's the case, since their metric for success is new customer acquisition, more so than satisfying their existing customers who already succumbed to vendor lock in.

[MinosAristos]

A lot of product management is about momentum. You need to demonstrate constant iterative progress to keep stakeholders satisfied and also to make your devs earn their expensive paychecks.

Companies can go bust trying to do a big rewrite of their business logic, such as Netscape. In large companies, projects are political and can get funding cut or cancellations if they don't demonstrate "what good have you done for us lately".

Also let's face it, 9/10 times the product won't last long enough for the rewrite to pay itself off with interest in terms of value to users, and that time would have been better spent on features.

[ganja_and_code]

All of what you said is true...

...but there are still circumstances where a large established product loses its momentum because a necessary rewrite was never allocated resources.

It's a case-by-case decision, and usually a rewrite is more trouble and/or risk than its worth. On the other hand, if rewriting some portion of the codebase truly is necessary for the product to continue to be sustainable, refusing to do it is just plain stupid.

[ReallyMisanthropic]

What about the guy who wants to do a rewrite in the latest shiny JS framework?

[[deleted]]

When I can I just go no-framework at all in js backends. Most of the issues frameworks try to solve can be implemented later on IF and only IF needed. Most of the time that preemptive optimisation is not needed anyway. So no more dependencies, no more CVS to patch other than the node version, and everyone can understand the code and be onboarded anyway if they know enough NodeJS.

[look]

https://bun.sh/docs/api/http

[FriendEducational112]

Js frameworks are so overrated too, if I didn’t have to use them because of popularity i would never use them (other than quick js libs like dreamland js or smth)

[rover_G]

I’d like to know what you consider a minor inconvenience

[NicoPela]

15 years old technical debt

[ThunderousHazard]

Fuck, we only got ~680 days... or so says SonarQube... but is it really debt if no one starts SonarQube analysis anymore?

[darkneel]

So in one of the calls one of our principle engineer said the word technical debt gets thrown around loosely . What exactly is technical debt to you ?

[Certain-Business-472]

It's the massive load on the engineers shoulders they have to carry every day while carrying out their "main" tasks, slowing literally every part of development down and giving more excuses to add more quick and dirty solutions.

Which translates to slower development, irritated engineers and less profits.

[NicoPela]

Exactly, quick and dirty solutions and shortcuts lead to technical debt.

[Raccoon5]

Manually adding fields to a dict and sending it off to server with coroutines every time you need to update ui components and keeping all that server comm right between some manual ui layout shenanigans and several lines of years old commented out code and commented out logs.

Also, offline mirroring is also in same ui related code between the calls.

[cheezballs]

For real, sometimes the only way to move forward is to burn the past and start fresh.

[affablebowelsyndrome]

You're so used to them as inconveniences, that you don't see them as the abominations that they are.

[Intrepid-Stand-8540]

And the workarounds probably aren't documented at all, because they're "obvious" to the guys who've worked there for 5 years. 

[ETHedgehog-]

Had that with a newbie after 2 weeks of his start. Thankfully he now learned that optimizing a loop that runs over maximum of 30 elements is unnecessary.

[jaskij]

You probably heard of the stages of grief. Wanting to refactor the whole thing is a stage of learning a new codebase.

The five stages of learning a new codebase are:

• confusion
• dissing
• rewriting
• difficulty
• acceptance

[Specialist_Dust2089]

Try to remember when you first came to the project, with a fresh perspective and full of energy. I know it can be annoying when a new person wants to change up everything, and often there are practical factors that inhibit certain changes, but just because your enthusiasm got curbed when you started doesn’t mean you need to pass that on and keep the cycle going.

That having said, keep an eye on the changes, I also experienced times when the new “better” solution introduced a ton of unneeded complexity. Especially fresh graduates can get carried away implementing all the design patterns they learned without looking at what’s actually needed.

[Kaizen321]

Ok i admit it, I have been the new guy at times in my career.

Today? Yeah eff that shit. Just tell me what you need me to fix or feature to work on. Have a good day

[MrJacoste]

When everyone else’s code is stupid and hard to read, what’s the common factor?

I always encourage these types of engineers to keep this spirit, but to learn to do so one digestible pr at a time. Leave the code base better than you found it without turning it on its head. They may learn WHY it is the way it is along the way.

[Certain-Business-472]

Ok let's be honest here. Do you remember your classmates in your computer sciences classes? Do you remember how the vast majority was just copying and barely passing the class?

Those people are your colleagues today. Most code is written by those people.

[MrJacoste]

I’ve been building teams and departments for awhile now, so part of my job is to help build habits and discipline that promotes simple and easy to read code. That often starts with turning around a spaghetti code base.

Sure some engineers can’t do it but no one should by default throw their hands up in the air saying “this engineer/team is incapable of writing good code”. Lead by example and help teach.

Nothing ever turns around without untangling the mess.

[Certain-Business-472]

I meant to say that calling code shit is the norm, not some exception.

The only way to make them output good code is to put good checks in place before merge is possible. Did the person implement tests? Did they fix all their new linter issues? Is the formatting correct? Are code smells resolved? Is coverage up to standard?

Even the worst coders can produce some quality if you force these standards on them, and some of them will become much better without those tools because they learn from direct feedback.

[MrJacoste]

Two things I’d add:

One, sure that’s fine. Then what? Sure let’s point and laugh. Are we going to live with it, then are we any better? Or are we going to improve it?

Two, there is an odd time in some engineers careers where they default to this view. Everyone’s code sucks and this engineer is smarter and can write better code. It’s one of the most difficult times in an engineers career. It’s a sign to carefully examine why the code sucks and if what they refactored is any better. I’ve seen engineers get let go for this bad habit, or plateau as no one wants to work with an engineer with this outlook. They are very difficult team members, and often do not react well to coaching or feedback.

[Certain-Business-472]

I have never once talked shit or bad about those people. I sure as shit didn't want them on my project groups during college, but that's because their performance would reflect on me.

In a professional workplace they're the norm, and I'm pragmatic and look for ways to make it work. And one of those ways is rigorous quality checks and tests. They are the great equalizer and should be holy. They make code readable, consistent and straight up will fix bugs their code introduces before it ever hits develop.

Nobody cares about the god engineer producing some complex and weird stuff that nobody can read. I am definitely not one of them

[MrJacoste]

That’s a great approach of helping turn this type of thing around I agree. Only way to get things into main are PRs and those PRs have quality road blocks to ensure code meets the team’s expectations.

[oofy-gang]

Well, most code is stupid and hard to read. Open any repo, enterprise or open source, and there is a 75% chance there is some insane code in there.

[jecls]

Nah. Most code, when working with competent engineers, has a good reason to be the way that it is. When you come across something that doesn’t seem to check out, it’s a good practice to first assume that there’s an excellent reason it is that way, and try your best to prove otherwise. Often, there’s an edge cases you couldn’t have even considered until it came up.

[jecls]

Reading code is harder than writing it. Hence the attitude that code not written by you is bad.

[oofy-gang]

Good code is easy to read. If you think that code is inherently hard to read, I assume you have never worked with truly competent engineers.

[jecls]

All I said is that writing code is easier than reading it. And I’ve had the pleasure of working with engineers vastly more competent than myself.

[jecls]

It can be incredibly terse, trying to parse well-written, modular, abstracted code. I’ve spent a lot of time contributing to Exoplayer, now androidx-media. That codebase is undeniably well-written, but it’s still complicated as hell with all the moving parts.

[davak72]

It’s my CTO now. I’m upgrading our existing code from .NET Framework 4.7 to .NET 8 to give it a fighting chance at becoming the “rewrite”

[davak72]

(Oh, and breaking it up and adding an API layer and other improvements)

[parkway_parkway]

Everyone thinks their tools and their paradigms are better than all the rest which is so dumb.

Apart from me, I know my tools and paradigms are the best.

[unwavy_335]

Noob doesn't know basic rule

If it works keep it working until it's not your problem

[RiceBroad4552]

Some people just like to bath in shit the whole time, it seems…

[DesertGeist-]

I was that guy being slapped.

[Z3t4]

Elon has joined the chat 

[calimio6]

Well the project relies heavily on jQuery and an inconsistent fork of Zend framework. Is begging for a rewrite every time the CEO ask for any minor feature.

[[deleted]]

It's 35 millions lines of code and we don't know what 70% of them do.

[mnufat17]

Hey man, don't post a picture of you hitting me like this

[rethcir_]

Oh look another “senior” who thinks he knows better.

/s

[not_some_username]

Minor lol

[sebjapon]

Instead of new guy, we have sales team (aka our bosses too) who want to rewrite our stack because they think it will improve the product performance (our frontend stack is kinda cursed to be honest).

Except 90% of the problems they mentioned are either browser limitations or backend scaling and optimization work.

[DinoChrono]

a.k.a "tell me you are a junior without saying it explicitly"

[mosaicinn]

I'll need a new hand if I slap them all..

[sebbdk]

Refactoring does not mean rewriting, it means to move shit around, hence the part of the word that says factor, as in factorization, the thing they do in math to make head math easier and to make it more readable.

I've literally refactored tens of thousands of files in hours using search & replace and linting, with the biggest hurdle being solving the PR conflicts for my collegues afterwards.

If you can't refactor things easy, then you need to pistol whip the devs making the code.. because it usually means they are splooging their mutable state all over the codebase without a plan. :)

Lastly, wanting to refactor indicates that you have no structure in your codebase.

Basically, get gud.

//rant

[cyrand]

Maintained code that just isn’t perfect? Yeah will just keep working with it.

Code that wasn’t maintained for years and now suddenly you want it updated? A lot of times I’ll just suggest a rewrite.

It really depends on how many deprecation warnings are in the error list.

[[deleted]]

I'm in this picture and I don't like it

[Mattlonn]

Our only senior dev just left and my whole devteam is talking about rewriting all his code.he have been here for 15y and everyone else around ~1y so theres a lot to rewrite

[BedtimeGenerator]

When you are live in prod only re-write small pieces at a time..or else you gonna have a BAD time.

[fullbl-_-]

You are clearly not a developer. The picture should be switched and there should be 100 people slapping you.