Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Hughlander
May 11, 2005

downout posted:

Contact them on your employers time since this is their fault.

Well obviously.

Much like you should always poo poo on company time for the way they poo poo on you.

Adbot
ADBOT LOVES YOU

SurgicalOntologist
Jun 17, 2004

Anyone have any good resources on how to think about the decision of rewriting a legacy code base? I have an engineer moving to a new codebase and reacting with "this is all poo poo, let's start over". Of course he's right, it is poo poo, but so will be whatever he replaces it with I'm sure. I've read some articles or heard discussions on podcasts or YT or whatever about this, but can't find them now. E.g. about taking into account the contexts of how the codebase originally evolved, especially if the original authors are no longer around, realizing that a rewrite will also face challenges, perhaps even the same ones, and also under time constraints so probably will also take less-than-optimal long-term design choices. I also remember seeing a study that an unfamiliar code base will always be rated as having a ton more technical debt than a familiar one even if they are similar quality (as difficult as that is to quantify).

I'm open to what this engineer wants to do but I'd like to push them to think a little deeper on some of these issues. Any suggestions?

Bongo Bill
Jan 17, 2012

The great rewrite in the sky is never as effective as you want it to be, but every once in a long while it's still worth it. Things to keep in mind:

  • Don't attempt feature parity with the old version. You are building a new product for the same market, so you still want to just target "minimum viable"
  • If you can, find a way to do it incrementally, and measure how much of it has been replaced, even with a crude metric like LOC
  • A useful pattern is to wrap the old system in a layer that has the interface you want, and initially just translates inputs and outputs, but can also start to do the work on its own
  • Never skimp on tests. In fact, add more tests to the old system, so you are more familiar with the behavior needed by the new system

Love Stole the Day
Nov 4, 2012
Please give me free quality professional advice so I can be a baby about it and insult you

Bongo Bill posted:

  • Don't attempt feature parity with the old version. You are building a new product for the same market, so you still want to just target "minimum viable"
Sorry mate, Product won't agree to retire the old features because it'd be too much revenue loss, and so now we're stuck 10 years later with an old component that nobody understands or knows how to maintain. Customer won't upgrade their integrations to the new APIs.

raminasi
Jan 25, 2005

a last drink with no ice

America Inc. posted:

I just got hired for a new senior frontend job in April but I would like a raise. In 3 months there will be a performance review and a bonus, but I want a raise in salary too if possible. What can I do to make that happen?

So far, I have a Google doc outlining the work I've done. It's a remote job so I've been scheduling coffee chats with everybody and getting to know people on the team.

But I need to make myself more visible. I am helping my coworkers - we've got a slack channel where people ask for help and I try to contribute to that. I arranged a meeting last Friday where I looped in one of our product owners and our UX designer to go over this feature I'm working on and iron out some questions.

My manager has been quite helpful and flexible - the job is based on the east coast, I'm on the west coast, and standup is at 7am, but he understands if I get up at 9 instead. We've been talking about setting goals and expectations but he seems kind of hesitant to do so until the 90 day probation period is over. I'd like to just ask "what do you need me to do to get a raise?"

There's more details but it would be helpful if someone has a guide of tips.

I've been trying to do freelance as well but that hasn't really panned out, the people I've talked to just aren't interested or perhaps I just suck at selling myself.

At most companies, the things necessary to get a raise are at best sort of vaguely adjacent to doing your job well. They don't necessarily detract from doing a good job, but don't fall into the common trap of trying to be really good at your job and expecting your employer to reward you with money. If your manager is good they'll come up with a plan to get you a raise, but don't be surprised if this plan is long and tedious and ultimately less efficient than just getting a new job.

Bongo Bill
Jan 17, 2012

Love Stole the Day posted:

Sorry mate, Product won't agree to retire the old features because it'd be too much revenue loss, and so now we're stuck 10 years later with an old component that nobody understands or knows how to maintain. Customer won't upgrade their integrations to the new APIs.

If you're not able to cut features, a rewrite from scratch cannot succeed.

Hughlander
May 11, 2005

SurgicalOntologist posted:

Anyone have any good resources on how to think about the decision of rewriting a legacy code base? I have an engineer moving to a new codebase and reacting with "this is all poo poo, let's start over". Of course he's right, it is poo poo, but so will be whatever he replaces it with I'm sure. I've read some articles or heard discussions on podcasts or YT or whatever about this, but can't find them now. E.g. about taking into account the contexts of how the codebase originally evolved, especially if the original authors are no longer around, realizing that a rewrite will also face challenges, perhaps even the same ones, and also under time constraints so probably will also take less-than-optimal long-term design choices. I also remember seeing a study that an unfamiliar code base will always be rated as having a ton more technical debt than a familiar one even if they are similar quality (as difficult as that is to quantify).

I'm open to what this engineer wants to do but I'd like to push them to think a little deeper on some of these issues. Any suggestions?

I like Working Effectively with Legacy Code, one of my teams just did a book club reading of it. Basically evolve don't rewrite, and only with a full test suite, to ensure the functionality isn't broken. Oh and here's how you add tests to legacy code that never had them without breaking the whole drat thing.

America Inc.
Nov 22, 2013

I plan to live forever, of course, but barring that I'd settle for a couple thousand years. Even 500 would be pretty nice.

Falcon2001 posted:

Best way to get a raise in a year is probably to job hop to a higher paid position. Is the pay untenable or do you just want more?

Money is tight for me this summer but things will clear up. I'd like more money so I can build up savings.

FlapYoJacks
Feb 12, 2009

America Inc. posted:

Money is tight for me this summer but things will clear up. I'd like more money so I can build up savings.

I too would like more money so I can have more money.

shame on an IGA
Apr 8, 2005

raminasi posted:

If your manager is good they'll come up with a plan to get you a raise, but don't be surprised if this plan is long and tedious and ultimately less efficient than just getting a new job.

the one time this has worked out for me it was because I was working on the building facilities team, HR had ordered new office furniture, and my boss took it hostage for 8 months.

lifg
Dec 4, 2000
<this tag left blank>
Muldoon
I hate rewriting code. I mean, I love it, but I also know I shouldn’t do it.

I look at it like this. There’s either one of two possibilities:

- The original programmer is doing the rewrite, in which case they’ll fall prey to the second system effect.
- The original programmer is not doing the rewrite, in which case they probably don’t know why the code got so bad in the first place, and why it’s so hairy, and what problems they’re going to encounter.

The old Joel Spolsky essay is a classic on this topic . https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

quote:

Well,” they say, “look at this function. It is two pages long! None of this stuff belongs in there! I don’t know what half of these API calls are for.”



Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

There’s something to be said for rewriting software if a lot the code would just not necessary with a more modern library or framework. But even then I’d still rather move the code into a black box than start fresh.

smackfu
Jun 7, 2004

I wonder if anyone has tried just rewinding the git history to when the code went to poo poo and rewriting from there?

SurgicalOntologist
Jun 17, 2004

lifg posted:

I hate rewriting code. I mean, I love it, but I also know I shouldn’t do it.

I look at it like this. There’s either one of two possibilities:

- The original programmer is doing the rewrite, in which case they’ll fall prey to the second system effect.
- The original programmer is not doing the rewrite, in which case they probably don’t know why the code got so bad in the first place, and why it’s so hairy, and what problems they’re going to encounter.

The old Joel Spolsky essay is a classic on this topic . https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

There’s something to be said for rewriting software if a lot the code would just not necessary with a more modern library or framework. But even then I’d still rather move the code into a black box than start fresh.

I think that was exactly the article I was thinking of, thanks! Edit: one of them at least

SurgicalOntologist fucked around with this message at 19:00 on Jun 28, 2023

steckles
Jan 14, 2006

SurgicalOntologist posted:

Anyone have any good resources on how to think about the decision of rewriting a legacy code base? I have an engineer moving to a new codebase and reacting with "this is all poo poo, let's start over". Of course he's right, it is poo poo, but so will be whatever he replaces it with I'm sure. I've read some articles or heard discussions on podcasts or YT or whatever about this, but can't find them now. E.g. about taking into account the contexts of how the codebase originally evolved, especially if the original authors are no longer around, realizing that a rewrite will also face challenges, perhaps even the same ones, and also under time constraints so probably will also take less-than-optimal long-term design choices. I also remember seeing a study that an unfamiliar code base will always be rated as having a ton more technical debt than a familiar one even if they are similar quality (as difficult as that is to quantify).

I'm open to what this engineer wants to do but I'd like to push them to think a little deeper on some of these issues. Any suggestions?
We get this every now and then. Parts of our code base are over 20 years old and sometimes a newish developer will get all "Let's rewrite this in Go/Rust/Lisp/Typescript/PHP/Plan9/Whatever" or "It'd be better if we switched to MongoDB/Elasticsearch/Postgres/Random NoSQL" or "Maybe we should switch to an SPA/Native Desktop App/Nintendo Virtual Boy cartridge" or whatever their pet favorite thing is. I usually remind them that it's the hundreds of little quality-of-life features that win us sales versus our competitors and most of those were added based on decades of user feedback and optimization for specific workflows and a rewrite that didn't exactly replicate the majority of them would piss people off.

If that doesn't work, putting them on one of our 6 hour long "deep dive" webinars that we do every few months will usually convince them that a rewrite is gonna be 1000x more work than they thought it be. We did once have a senior developer who decided that any new development was throwing good money after bad and dedicated his time to arguing with the CTO and spreading fud about the software's future to the COO and CEO. I regret not firing him sooner.

I always want to refactor some of the hairier parts of the codebase, but getting buy-in for that is always difficult and usually seems less appealing to the let's-rewrite-everything types.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

smackfu posted:

I wonder if anyone has tried just rewinding the git history to when the code went to poo poo and rewriting from there?

Git... History?

Is that like when I make a copy paste of the folder with the app every month?

prom candy
Dec 16, 2005

Only I may dance
A thing I heard was something along the lines of if you have a poo poo codebase and it's preventing you from iterating and adding new features and you don't rewrite, eventually a competitor will rewrite it themselves and steal your customers. They gave the example of some salon management tool that everyone in the industry used but hated that got absolutely bodied by a competitor who offered more or less the same thing but not poo poo.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

prom candy posted:

A thing I heard was something along the lines of if you have a poo poo codebase and it's preventing you from iterating and adding new features and you don't rewrite, eventually a competitor will rewrite it themselves and steal your customers. They gave the example of some salon management tool that everyone in the industry used but hated that got absolutely bodied by a competitor who offered more or less the same thing but not poo poo.

That's just every niche industry software though.

Love Stole the Day
Nov 4, 2012
Please give me free quality professional advice so I can be a baby about it and insult you

prom candy posted:

A thing I heard was something along the lines of if you have a poo poo codebase and it's preventing you from iterating and adding new features and you don't rewrite, eventually a competitor will rewrite it themselves and steal your customers.
My favorite part is when the rewrite and the legacy EOL migrations get deprioritized, in favor of reinventing the wheel once again with even more integrations and knowledge silos.

ploots
Mar 19, 2010
“The same thing I already use but not poo poo” is the kind of killer feature customers will crawl over broken glass to get.

(Un)fortunately it’s impossible to pull off because all software is poo poo.

shame on an IGA
Apr 8, 2005

smackfu posted:

I wonder if anyone has tried just rewinding the git history to when the code went to poo poo and rewriting from there?

they tried but Ada Lovelace had never checked anything in to the repo

Plorkyeran
Mar 22, 2007

To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

smackfu posted:

I wonder if anyone has tried just rewinding the git history to when the code went to poo poo and rewriting from there?

I have done this with unmaintained third-party things. In one case the developer tried to do things which would have made it a lot better but burned out on the project while it was in a rough state and we didn't want to take on the task of trying to finish that work. In another it was an already-dead project that we expected to mostly rewrite but thought would be an easier starting point than starting from scratch. All of the functionality we cared about was added fairly early on so we started from a version from before it scope-crept to do a bunch of other things.

Turambar
Feb 20, 2001

A Túrin Turambar turun ambartanen
Grimey Drawer

shame on an IGA posted:

they tried but Ada Lovelace had never checked anything in to the repo

Well, she did make a pull request:

https://twitter.com/ninabegus/status/1574434557973012480

ThePopeOfFun
Feb 15, 2010

i had a long rant but gently caress react

spiritual bypass
Feb 19, 2008

Grimey Drawer
Was it a whole megabyte before compression?

Macichne Leainig
Jul 26, 2012

by VG
JavaScript code:
import { rant } from "emotions";
Bundle size: +23.76Mb

Cup Runneth Over
Aug 8, 2009

She said life's
Too short to worry
Life's too long to wait
It's too short
Not to love everybody
Life's too long to hate


ThePopeOfFun posted:

i had a long rant but gently caress react

I love that all programming is slowly becoming web development

ThePopeOfFun
Feb 15, 2010

lmao. Just growing pains. I’m very new, and while learning eventing, states, useEffects, components, etc. I feel insane knowing I could whip up the same thing in a fraction of the time. Of course it wouldn’t be reusable or scale, but ya know.

Cup Runneth Over
Aug 8, 2009

She said life's
Too short to worry
Life's too long to wait
It's too short
Not to love everybody
Life's too long to hate


Ah, you want to build software? Well we call them apps now first of all, but secondly, would you like to use Node.js, or React.js?

spiritual bypass
Feb 19, 2008

Grimey Drawer
The backend needs to be highly scalable and also Python

lifg
Dec 4, 2000
<this tag left blank>
Muldoon

prom candy posted:

A thing I heard was something along the lines of if you have a poo poo codebase and it's preventing you from iterating and adding new features and you don't rewrite, eventually a competitor will rewrite it themselves and steal your customers. They gave the example of some salon management tool that everyone in the industry used but hated that got absolutely bodied by a competitor who offered more or less the same thing but not poo poo.

I believe that a company who made the industry leading product isn’t capable of making a better, nimbler version. It goes beyond a need to rewrite code. It’s institutional. They can’t even look at a simple user requirement without turning it into an enterprise-level misunderstanding.

America Inc.
Nov 22, 2013

I plan to live forever, of course, but barring that I'd settle for a couple thousand years. Even 500 would be pretty nice.

prom candy posted:

A thing I heard was something along the lines of if you have a poo poo codebase and it's preventing you from iterating and adding new features and you don't rewrite, eventually a competitor will rewrite it themselves and steal your customers. They gave the example of some salon management tool that everyone in the industry used but hated that got absolutely bodied by a competitor who offered more or less the same thing but not poo poo.

The last place I worked at had a 30+ yr codebase of lasagna layers of C and C++ and adding new features often required working around tech debt. The pace of development was glacial. Despite that, they're still the industry leader with a lot of buy-in from big companies and healthy profit margin.

So I don't think that's true, it's more about the product itself than the code.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

SurgicalOntologist posted:

Anyone have any good resources on how to think about the decision of rewriting a legacy code base? I have an engineer moving to a new codebase and reacting with "this is all poo poo, let's start over". Of course he's right, it is poo poo, but so will be whatever he replaces it with I'm sure. I've read some articles or heard discussions on podcasts or YT or whatever about this, but can't find them now. E.g. about taking into account the contexts of how the codebase originally evolved, especially if the original authors are no longer around, realizing that a rewrite will also face challenges, perhaps even the same ones, and also under time constraints so probably will also take less-than-optimal long-term design choices. I also remember seeing a study that an unfamiliar code base will always be rated as having a ton more technical debt than a familiar one even if they are similar quality (as difficult as that is to quantify).

I'm open to what this engineer wants to do but I'd like to push them to think a little deeper on some of these issues. Any suggestions?

https://www.amazon.com/Kill-Fire-Manage-Computer-Systems/dp/1718501188 This book is basically a very detailed discussion of that specific topic; I can't recommend it enough for what you're asking. It specifically does a good job of talking about the risks people underestimate with greenfield solutions.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

I honestly just want to print this out, crumple it up, and throw it at relevant parties.

redleader
Aug 18, 2005

Engage according to operational parameters

cum jabbar posted:

The backend needs to be highly scalable and also Python

you're losing out on the incredible benefits of isomorphic js

thotsky
Jun 7, 2005

hot to trot

Bongo Bill posted:

Don't attempt feature parity with the old version. You are building a new product for the same market, so you still want to just target "minimum viable"

Feature parity is by definition the minimum viable for any rewrite (for most stakeholders).

I agree with you, but lol.

thotsky fucked around with this message at 10:48 on Jun 29, 2023

Xguard86
Nov 22, 2004

"You don't understand his pain. Everywhere he goes he sees women working, wearing pants, speaking in gatherings, voting. Surely they will burn in the white hot flames of Hell"

lifg posted:

I believe that a company who made the industry leading product isn’t capable of making a better, nimbler version. It goes beyond a need to rewrite code. It’s institutional. They can’t even look at a simple user requirement without turning it into an enterprise-level misunderstanding.

Can't even make a six panel cartoon of a fake user using a fake product without shoving in ten extra things each with a redundant conversation about what this person is trying to do.

smackfu
Jun 7, 2004

redleader posted:

you're losing out on the incredible benefits of isomorphic js

My favorite part of isomorphic js is that you have to run your interpreted JavaScript code through a build step so it can run in both places.

Pollyanna
Mar 5, 2005

Milk's on them.


thotsky posted:

Feature parity is by definition the minimum viable for any rewrite (for most stakeholders).

I agree with you, but lol.

That’s if it’s a rewrite, and not a replacement. If the reality is that what stakeholders want can be achieved with a significantly streamlined or simplified product, that would not be feature parity, but it would be minimum viable.

I think a shitload of products could be replaced by something simpler and streamlined. But I also think few benefit from a rewrite instead of smaller refactors or, better yet, revised architecture and product design.

spiritual bypass
Feb 19, 2008

Grimey Drawer

Pollyanna posted:

That’s if it’s a rewrite, and not a replacement. If the reality is that what stakeholders want can be achieved with a significantly streamlined or simplified product, that would not be feature parity, but it would be minimum viable.

I think a shitload of products could be replaced by something simpler and streamlined. But I also think few benefit from a rewrite instead of smaller refactors or, better yet, revised architecture and product design.

One of my favorite things about doing webapps is rewriting code for a specific URL. Leave the other legacy poo poo in place and make just one slow or heavily used thing fast and reliable (unless it's the database that's choking lol)

Adbot
ADBOT LOVES YOU

Macichne Leainig
Jul 26, 2012

by VG
This guy at work just unironically added me to four slack channels that haven't seen use since April at the latest, and then left two of them because "I am doing some clean up in my Slack channel chaos."

Two can play that game motherfucker

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply