Hacker News Reader

Comment by JohnBooty | Hacker News Reader

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.

View on HN

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.

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!

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.

I stopped leaving comments like this because I encountered some surprisingly vitriolic resistance to making comments readable.

Yep, I've been yelled at for both ways. Not putting any effort toward it at this point.

It's definitely a daunting task, and I've been in that position once and I think it was a pivotal role in my career. I was hired as the only android engineer on a project that had churned 3 devs already, each with their own code style, and they all built layers on top of one another. It's hard to be in the position where a full re-write would be simpler technically, but impossible politically. My strategy was to basically refactor layer by layer, bringing the codebase back to a mostly working state in between modules. Over the course of 6 months I basically re-wrote the whole app and reduced the LOC by 50% while taking our crash rate from ~10 percent to < 1 percent. It was painful, but I'm no longer overwhelmed or overly annoyed by legacy code filled with cruft. It really is possible to chip away at it piece by piece and end up in a great position, and knowing how to pull that off is what separates the good from the great. Theres no perfect codebase, and having the skills to continually refactor and improve while delivering features is key.

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.

    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.

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.

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.

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.

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.

Do you literally do this?

What if the manager still insists you add features? Throw pebbles at the manager until you're fired and arrested?

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

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.

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)

Reply on news.ycombinator.com