3 ms·

Understanding unfamiliar legacy code with a bunch of kludges and "domain knowledge" or "business logic" baked into it, when the original authors are unintereste

Understanding unfamiliar legacy code with a bunch of kludges and "domain knowledge" or "business logic" baked into it, when the original authors are uninterested/unavailable and management has zero respect or understanding for the fact that it often takes an order of magnitude longer to modify/maintain this stuff than it does to write it. Oh, and there's no test suite. That is my nightmare. I've been there a few times and it can be literally impossible to shine in that role. "What do you mean, it will take you ten hours to add a button? They coded this whole module in one week and there are 100 buttons!" aarrrrgh Now, as an engineer, I understand and embrace the challenge of explaining this sort of thing to management. I get it. That's the type of skill that separates code monkeys from senior developers and architects. But, no matter how good you are, you can't force management to listen nor understand.

xvilka 7y ago
Well, if manager is blind to your explanations, then it means it is better to search for a new job. Time is precious, and nothing good can come out of this work.
retiredcoder 7y ago
It can get worse, when the managers are the ones who wrote the legacy and still are actively acting as individual contributors themselves instead of empowering their own people
- Roritharr 7y ago
  How about we add financial pressure to the mix that doesn't allow you to invest in anything so you're forced to add even more weirdness to the pile of crap instead.
  - retiredcoder 7y ago
    True, specially when management is much more invested financially in the company than rank and file engineers. That happens a lot in European startup scene from my observations (as equity comp here isn’t that appealing for most of ICs)
mikekchar 7y ago
If you are on a legacy project, it's hard to know what to prioritise in terms of improving code. However, getting requests to take somewhere within an order of magnitude of how long people think it should take is usually my guide. I never tell people I'm going to refactor something. I just do it. Then after the fact I say, "Remember when this used to take a week? Now it takes an hour". Once you do that a couple of times, management gets the point (usually). The only problem I've come across is when you get on a team where they actively discourage code churn. On a legacy project, that's death, so it's best to find another job in that case. I really enjoy working on legacy code. Usually everybody else leaves me alone because nobody wants to touch that code. I get a tonne of freedom. As long as I don't break things (requires a fair amount of experience) I can quietly improve things under the hood -- targeting areas where we get a lot of requests. Legacy code is also great because usually nobody wants new features just for the hell of it. You almost always get real requests from real users that have real pain points. The biggest downside (as you imply) is that it's hard to shine because the best you can do is make things acceptable. It's difficult to hype the legacy project so you don't get a lot of recognition for your work.
- JohnBooty 7y ago
  I liked reading this! I'm glad you found happiness doing this sort of work! One thing I'd say is that it's awfully tough to do this sort of work as a contractor when there's a (direct) hourly cost for your time. It's tough when you're on salary working on an internal project... but doubly tough (not impossible) when you're a contractor! Theoretically, it would be in clients' best interests to improve efficiencies, but it's really hard to get a client to sign off on hundreds or many thousands of dollars of work for a future gain that's hard for them to grasp. (Getting them to grasp it is part of our job, of course) Then after the fact I say, "Remember when this used to take a week? Now it takes an hour". Once you do that a couple of times, management gets the point (usually) This is great advice. It's all about those metrics and demonstrating the value of your work!
  - majewsky 7y ago
    Please don't use codeblocks for quoting. This quote is unreadable on most screens (esp. on mobile) because the line doesn't break. Just put a > in front of a normal paragraph to indicate a quote.
alxlaz 7y ago
Oh yeah. I've spent my last (almost) three years (thankfully they're over now) working on that kind of codebase and it's been an absolute nightmare. The very few original(-ish) authors still on the team were generally very helpful, but the codebase was huge, some of it was bought from someplace else (so there was no one to explain anything, and no documentation because of course not), and the team had been downsized in the course of time. Patching it up with contractors, needless to say, didn't quite have the stellar effect that management had hoped it would have. Three years later I was still struggling to figure out even the most basic of features. It would regularly take me days, sometimes even weeks to fix trivial bugs. The convoluted code definitely didn't help (message passing between several processes, 4000-line functions...). There were a lot of features that I could barely use, let alone debug. I had no mental model of the code at all. Figuring out where my mental model didn't match reality was pretty much out of the question under the circumstances -- and my only source for creating a mental model of the code was, well, the buggy code. Thankfully, I also worked on other things during these three years, so my sanity is still mostly intact. But that thing was really terrible.
- JohnBooty 7y ago
  The convoluted code definitely didn't help (message passing between several processes, 4000-line functions...) Oh man, yeah. This kind of thing's hard enough in a single threaded monolith, much less when you've got multiple processes! One time I was actually able to kill/retire a whole bunch of external processes and bring stuff back into the monolith. Yeah it made the monolith 1% bigger or whatever, but I think it was 100x better than throwing more services into the absolute gangbang of dependencies in which we were already drowning. I'm glad you were able to move on and had other stuff to work on. Looking back, I probably should have just found another job rather than push through those legacy maintenance slogs. Lost sleep and hair for years, and it was sort of a career black hole.
ChrisRR 7y ago
I have that problem even worse in that I have to work with a developer who will actively develop like that. Every time he has to add a feature, instead of adding it into the relevant module, he'll add it into 2 or 3 different module which have the knock-on effect of doing what he wants. It took me months to take his spaghetti code, modularise it, and yet still every time he commits is a constant argument of things being in the wrong place in code.
- JohnBooty 7y ago
  And of course, management often loves that sort of dude. The burden of proof is usually on you to prove why your slower-in-the-short-term approach is better than that guy's approach, which will get working code into production two hours from now.
amelius 7y ago
Use a glass. Every time a manager asks you to implement a feature in an unrealistic timeframe, you drop one or more pebbles into the glass. When the glass is full, no more features can be added. When management gives you time to restructure your code, you remove some pebbles from the glass.
- JohnBooty 7y ago
  Do you literally do this?
- antisemiotic 7y ago
  What if the manager still insists you add features? Throw pebbles at the manager until you're fired and arrested?

xvilka 7y ago

Well, if manager is blind to your explanations, then it means it is better to search for a new job. Time is precious, and nothing good can come out of this work.

retiredcoder 7y ago

It can get worse, when the managers are the ones who wrote the legacy and still are actively acting as individual contributors themselves instead of empowering their own people

Roritharr 7y ago
How about we add financial pressure to the mix that doesn't allow you to invest in anything so you're forced to add even more weirdness to the pile of crap instead.
- retiredcoder 7y ago
  True, specially when management is much more invested financially in the company than rank and file engineers. That happens a lot in European startup scene from my observations (as equity comp here isn’t that appealing for most of ICs)

mikekchar 7y ago

If you are on a legacy project, it's hard to know what to prioritise in terms of improving code. However, getting requests to take somewhere within an order of magnitude of how long people think it should take is usually my guide. I never tell people I'm going to refactor something. I just do it. Then after the fact I say, "Remember when this used to take a week? Now it takes an hour". Once you do that a couple of times, management gets the point (usually). The only problem I've come across is when you get on a team where they actively discourage code churn. On a legacy project, that's death, so it's best to find another job in that case. I really enjoy working on legacy code. Usually everybody else leaves me alone because nobody wants to touch that code. I get a tonne of freedom. As long as I don't break things (requires a fair amount of experience) I can quietly improve things under the hood -- targeting areas where we get a lot of requests. Legacy code is also great because usually nobody wants new features just for the hell of it. You almost always get real requests from real users that have real pain points. The biggest downside (as you imply) is that it's hard to shine because the best you can do is make things acceptable. It's difficult to hype the legacy project so you don't get a lot of recognition for your work.

JohnBooty 7y ago
I liked reading this! I'm glad you found happiness doing this sort of work! One thing I'd say is that it's awfully tough to do this sort of work as a contractor when there's a (direct) hourly cost for your time. It's tough when you're on salary working on an internal project... but doubly tough (not impossible) when you're a contractor! Theoretically, it would be in clients' best interests to improve efficiencies, but it's really hard to get a client to sign off on hundreds or many thousands of dollars of work for a future gain that's hard for them to grasp. (Getting them to grasp it is part of our job, of course) Then after the fact I say, "Remember when this used to take a week? Now it takes an hour". Once you do that a couple of times, management gets the point (usually) This is great advice. It's all about those metrics and demonstrating the value of your work!
- majewsky 7y ago
  Please don't use codeblocks for quoting. This quote is unreadable on most screens (esp. on mobile) because the line doesn't break. Just put a > in front of a normal paragraph to indicate a quote.

alxlaz 7y ago

Oh yeah. I've spent my last (almost) three years (thankfully they're over now) working on that kind of codebase and it's been an absolute nightmare. The very few original(-ish) authors still on the team were generally very helpful, but the codebase was huge, some of it was bought from someplace else (so there was no one to explain anything, and no documentation because of course not), and the team had been downsized in the course of time. Patching it up with contractors, needless to say, didn't quite have the stellar effect that management had hoped it would have. Three years later I was still struggling to figure out even the most basic of features. It would regularly take me days, sometimes even weeks to fix trivial bugs. The convoluted code definitely didn't help (message passing between several processes, 4000-line functions...). There were a lot of features that I could barely use, let alone debug. I had no mental model of the code at all. Figuring out where my mental model didn't match reality was pretty much out of the question under the circumstances -- and my only source for creating a mental model of the code was, well, the buggy code. Thankfully, I also worked on other things during these three years, so my sanity is still mostly intact. But that thing was really terrible.

JohnBooty 7y ago
The convoluted code definitely didn't help (message passing between several processes, 4000-line functions...) Oh man, yeah. This kind of thing's hard enough in a single threaded monolith, much less when you've got multiple processes! One time I was actually able to kill/retire a whole bunch of external processes and bring stuff back into the monolith. Yeah it made the monolith 1% bigger or whatever, but I think it was 100x better than throwing more services into the absolute gangbang of dependencies in which we were already drowning. I'm glad you were able to move on and had other stuff to work on. Looking back, I probably should have just found another job rather than push through those legacy maintenance slogs. Lost sleep and hair for years, and it was sort of a career black hole.

ChrisRR 7y ago

I have that problem even worse in that I have to work with a developer who will actively develop like that. Every time he has to add a feature, instead of adding it into the relevant module, he'll add it into 2 or 3 different module which have the knock-on effect of doing what he wants. It took me months to take his spaghetti code, modularise it, and yet still every time he commits is a constant argument of things being in the wrong place in code.

JohnBooty 7y ago
And of course, management often loves that sort of dude. The burden of proof is usually on you to prove why your slower-in-the-short-term approach is better than that guy's approach, which will get working code into production two hours from now.

amelius 7y ago

Use a glass. Every time a manager asks you to implement a feature in an unrealistic timeframe, you drop one or more pebbles into the glass. When the glass is full, no more features can be added. When management gives you time to restructure your code, you remove some pebbles from the glass.

JohnBooty 7y ago
Do you literally do this?
antisemiotic 7y ago
What if the manager still insists you add features? Throw pebbles at the manager until you're fired and arrested?