Mistakes engineers make in large established codebases • Hacker News Board

Re: Mistakes engineers make in large established codebases

#221

Post by physicsguy » Wed, Jan 08, 2025, 9:47 AM UTC

A big problem I come across is also half-assing the improvements.

Taks as an example - for some reason you need to update an internal auth middleware library, or a queue library - say there is a bug, or a flaw in design that means it doesn't behave as expected in some circumstances. All of your services use it.

So someone comes along, patches it, makes the upgrade process difficult / non-trivial, patches the one service they're working on, and then leaves every other caller alone. Maybe they make people aware, maybe they write a ticket saying "update other services", but they don't push to roll out the fixed version in the things they have a responsibility for.

Re: Mistakes engineers make in large established codebases

#222

Post by cess11 » Wed, Jan 08, 2025, 9:54 AM UTC

Very good advice. An implication from being reluctant to introducing dependencies is that you should remove dependencies if you can. Perhaps different parts of the system is using different PDF-generation libraries, or some clever person introduced Drools at some point but you might as well convert those rules to plain old Java.

Tooling is important too. IDE:s are great, but one should also use standalone static analysis, grepping tools like ripgrep and ast-grep, robust deterministic code generation, things like that.

Re: Mistakes engineers make in large established codebases

#223

Post by fedeb95 » Wed, Jan 08, 2025, 9:57 AM UTC

this should be tattooed to every newly hired CTO arm.

Re: Mistakes engineers make in large established codebases

#224

Post by bogdan » Wed, Jan 08, 2025, 10:06 AM UTC

Kinrany wrote: post #212

pablobaz wrote: post #62

In my experience with very large codebases, a common problem is devs trying to improve random things. This is well intentioned. But in a large old codebase finding things to improve is trivial - there are thousands of them. Finding and judging which things to improve that will actually have a real positive impact is the real skill. The terminal case of this is developers who in the midst of another task try improve o…

Do you think boyscouting, "leave it better than you found it" is misguided as well?

I always took it as "leave it better than you found it" across the files that I've been working on (with some freedom as long I'm on schedule). My focus is to address the ticket I'm working on. Larger improvements and refactorings get ticketed separately (and yes, we do allocate time for them). In other words, I don't think it's misguided.

Re: Mistakes engineers make in large established codebases

#225

Post by watt » Wed, Jan 08, 2025, 10:13 AM UTC

baq wrote: post #186

zwnow wrote: post #183

Earlier quoted context omitted.

The issue is that management usually doesn't care. Personally I usually have about 3-4 days to implement something. If I can't deliver they will just look for more devs, yes. Quantity is what matters for management. New New New is what they want, who cares about the codebase (sarcasm). Management doesn't even know how a good codebase looks. A bridge that is missing support probably wouldn't have been opened to the pu…

> The issue is that management usually doesn't care. Neither do customers. The product is an asset. Code is a liability.

Sounds like a dogma that got us (as industry) into this mess.

Re: Mistakes engineers make in large established codebases

#226

Post by watwut » Wed, Jan 08, 2025, 10:13 AM UTC

peterldowns wrote: post #72

digging wrote: post #67

Earlier quoted context omitted.

> If it's actually better, others will start following your lead. Not really my experience in teams that create inconsistent, undocumented codebases... but you might get 1 or 2 converts.

It depends on the day but generally I believe that most engineers want to write good code, want to improve their own skills, and like learning and critiquing with other engineers. Sometimes a small catalyst is all it takes to dramatically improve things. Most of the times I've thought that individual contributors were the problem, the real issue was what the company's leaders were punishing/rewarding/demanding.

Sure, but that does not imply they will follow whatever you found out to be the best for the piece of code you are working on right now.

Re: Mistakes engineers make in large established codebases

#227

Post by codingdave » Wed, Jan 08, 2025, 10:24 AM UTC

Animats wrote: post #169

> Single-digit million lines of code (~5M, let’s say) > Somewhere between 100 and 1000 engineers working on the same codebase > The first working version of the codebase is at least ten years old That's 5,000 to 50,000 lines of code per engineer. Not understaffed. A worse problem is when you have that much code, but fewer people. Too few people for there to be someone who understands each part, and the original autho…

Being able to navigate and reverse engineer undocumented legacy code in a non-modern stack is a skill set in and of itself. Most people don't enjoy it in the slightest, so being one of the few devs who does means that I have been able to take on the gnarly legacy problems nobody else will touch. It might not build buzzwords on my resume, which does limit using this particular aspect of dev work to get an initial call back on jobs. But it absolutely exposes me to a variety of ways of doing things and expands my skills in new directions, and that expanded perspective does help in interviews.

You lost me on how this helps employers keep salaries down. My value is greater by being able to do such things, not less. If I can work on modern stacks, legacy stacks, enterprise platforms, and am willing to learn whatever weird old tech you have, that does not decrease my salary.

Re: Mistakes engineers make in large established codebases

#228

Post by arkh » Wed, Jan 08, 2025, 10:32 AM UTC

yid wrote: post #195

newaccountman2 wrote: post #135

Earlier quoted context omitted.

Am I naive for thinking that nothing like that should take as long as 6-9 months in the happy case and that it's absurd for it to not succeed at all?

> Am I naive for thinking that nothing like that should take as long as 6-9 months in the happy case and that it's absurd for it to not succeed at all? Bluntly, yes. And so is every other reply to you that says "no this isn't naive", or "there's no reason this project shouldn't have finished". All that means is that you've not seen a truly "enterprise" codebase that may be bringing in tons of business value, but whos…

> whose internals are a true human centipede of bad practices and organic tendrils of doing things the wrong way

Currently there. On one hand: lot of old code which looks horrible (the "just put comments there in case we need it later" pattern is everywhere). Hidden scripts and ETL tasks on forgotten servers, "API" (or more often files sent to some FTP) used by one or two clients but it's been working for more than a decade so no changing that. On the other: it feels like doing archeology, learning why things are how they are (politics, priority changes over the years). And when you finally ship something helping the business with an easier to use UI you know the effort was not for nothing.

Re: Mistakes engineers make in large established codebases

#229

Post by noisy_boy » Wed, Jan 08, 2025, 10:42 AM UTC

KronisLV wrote: post #207

> If they use some specific set of helpers, you should also use that helper (even if it’s ugly, hard to integrate with, or seems like overkill for your use case). You must resist the urge to make your little corner of the codebase nicer than the rest of it. This reads like an admission of established/legacy codebases somewhat sucking to work with, in addition to there being a ceiling for how quickly you can iterate,…

> like docs that tell you about the 10 abstraction layers needed to get data from an incoming API call through the database and back to the user,

docs.. lol

Re: Mistakes engineers make in large established codebases

#230

Post by sebstefan » Wed, Jan 08, 2025, 10:47 AM UTC

KronisLV wrote: post #207

> If they use some specific set of helpers, you should also use that helper (even if it’s ugly, hard to integrate with, or seems like overkill for your use case). You must resist the urge to make your little corner of the codebase nicer than the rest of it. This reads like an admission of established/legacy codebases somewhat sucking to work with, in addition to there being a ceiling for how quickly you can iterate,…

> Plus, the more you couple things, the harder it will be to actually change anything, if you don't have enough of the aforementioned test coverage

The author cites some imaginary authentication module where "bot users" are a corner case, and you can imagine how lots of places in the software are going to need to handle authentication at some point

Say you don't use the helper function. Do you think you've avoided coupling?

The thing is, you're already coupled. Even if you don't use it

Fundamentally, at the business level, your code is coupled to the same requirements that the helper function helps to fullfil.

Having a separate implementation won't help if one day the requirements change and we suddenly need authentication for "super-bot" users. You'll now need to add it to two different places.