Ask HN: How do you maintain a legacy codebase solo?

6 points by bodegajed 2 days ago | 8 comments

Hey friends, I hope you are all doing well. So, I've been studying the recent layoffs.fyi annual data, It seems the great reshuffle has slowed down.

It has been months since I got hired by a small company. I suspect everyone here got laid off before I was hired because by looking at the names of the commit logs, I can see that these people are all absent from the company.

I'm already burned out with this new position as a solo dev ai/ml full-stack software engineer.

Let me share my thoughts for a moment:

I'm mostly on non-coding activities when maintaining existing code

It's hard to provide estimates. Work is done by theorizing logically meaningful sequences for a real-world business requirement, usually in unpredictable, non-linear pain to comfort velocity.

Abstractions and functions have deeper design theories, and therefore, the user story must be understood when it is theorized and written. We have to assess the previous dev's choices and why the current was picked.

Tacit knowledge - on which we create a mental list of value-assessed design choices and their theoretical contribution to the next item in the sequence. Eventually, leading their overall contribution to the real-world business model.

i.e. if the business required this line of code to be made, therefore there is a value-metric involved, and this must be carefully assessed before altering the code.

Given a threshold of comfort, only then can we possibly alter the code. Deducing and isolating the root cause and, lastly, reproducing the error.

How do you handle legacy code? How do you explain this to your new boss? This full no-scope full-stack 360 is very overwhelming; I'm already burned out while job hunting. I provide them estimates and miss by a wide margin. I don't wanna go back to the job market.

saluki 7 hours ago | next |

Forget about best practices and refactoring.

You'll need to duplicate existing code and make it your own or risk adding one piece of new functionality and breaking things that were using that code in 20 unexpected places.

Build new isolated code with best practices.

You'll slowly become familiar with it and get a feel for the best way to make updates and changes safely.

Jugurtha 18 hours ago | prev | next |

Hi.

To answer your question as formulated in the title: is it worth it?

For further feedback, could you write differently than someone trying to justify their job to a non-technical person who can fire them by stretching boundary induced theorized neuro-transmitted user experience triggering value-releasing velocity multipliers? You're safe here; I didn't understand what you wrote.

svilen_dobrev 2 days ago | prev | next |

Somewhat clarifying question: do they care about it? or not so much? i.e. if you are the only one, and you don't have the needed freedom/ time/ resources/ help-from-everyone-else..

Anyway, legacy code should be tread very lightly, esp. one with missing why's. Your job becomes finding those why's .. and most of those may have nothing software-ish in them.

One simple single-aspect change at a time. Try it.. checking it does not go regression (might be impossible - well, then Hoping it won't). Undo or go-forward. Repeat.

Write down/Document everything you find. Or assume. Or think of. (do it for your future self)

and yes, have Fun.. the always missed part of the trio functionality-quality-time

bodegajed 2 days ago | root | parent |

Thanks for these suggestions. That is really good advice, writing down gained knowledge and assumptions, then presenting it to them for clarification or my future self. The codebase is quite massive, and while they have tests, the coverage is just a fraction. So, I might need to build more. To answer your question, I think the industry expectations have changed with AI and the BS of big-tech CEOs. But that is just me guessing based on the pressure I'm receiving.

svilen_dobrev 3 hours ago | root | parent |

Try to make map/s. Something visual. Of one or multiple aspects. Cross-reference func/class is easiest but too low level ; needed is crossreference of notions - in space AND time.

Did such thing several times, helps a lot. in my last gig i landed as "owner" of 300K js , in-house event-sourcing-from-scratch.. a complicated mess although somehow organised because of the events. There was a team working on those, but in somewhat darkness - noone knew why x-y-z is so. After some staring at code for a while, found few patterns - some repeated, some once-off, and build a mapper (i am python guy, used Esprima as js parser) to extract and build the graph of domain-event-reason-consequence for all available cases, then made visual maps of those 4 aspects (graphviz). And although noone from the team learned to look/use those, i used them, to guess eventual consequences of some change or answer why this-and-that happened, and shown to various interested parties as "very elevated documentation" :)

uncomplexity_ 2 days ago | prev | next |

rule 1 dont try to be clever by refactoring

rule 2 underpromise so you can overdeliver. if you dont meet your short deadline they'll think you're lazy or incompetent. if finish in your long deadline they'll think you are employee of the month. always x2 or x3 your estimates.

rule 3 hang out with the seniors, listen to them. they know the landmines and how things are. not only in technical but also in office politics.

rule 4 spend time with people closest to your end users. this may be your sales people and support people. they dont code, they dont know the inner technicals, but they know the things that matter business wise.

bodegajed 2 days ago | root | parent |

Thanks, yes, refactoring. Please allow me to vent.

First, I totally agree with you on Rule No. 1. I would never refactor legacy code or suggest a rewrite. It's always a terrible idea. The downside is that I worry I might look like a ghost engineer. This is why I hate this industry sometimes. I heard about this paper at Stanford on ghost engineers a few weeks ago. Where LOC as their basis, it's just absurd. It went to the mainstream media as well, but looking at the paper, it has no metrics on the non-coding aspect of programming.

It seems the industry hates the dev, like we should not be paid this high. Did execs make poor product choices? Let's fix this by increasing shareholder value by another round of layoffs. Which department? Engineering, we have metrics who does not provide enough value!

brudgers 2 days ago | prev |

How do you explain this to your new boss?

Needing to explain the complexity of the task to your boss, might suggest the reasons none of the previous committers are still working at the company.

Of course it might be coincidence that you are already feeling burnt out; the company has not retained developers before you; and does not have relationships with those developers where they are available as consultants.

If you decide it probably isn’t coincidence, it might make sense to have workplace expectations consistent with such a company culture.

Sometimes a lousy job is better than looking for a job. Sometimes it’s not. Good luck.