Mistakes engineers make in large established codebases • Hacker News Board

Re: Mistakes engineers make in large established codebases

#161

Post by awesome_dude » Wed, Jan 08, 2025, 4:22 AM UTC

peterldowns wrote: post #152

citizenpaul wrote: post #106

Earlier quoted context omitted.

>Not really my experience in teams that create inconsistent, undocumented codebases... but you might get 1 or 2 converts. This has also been my experience. Usually there is a "Top" sticky/unhelpful/reticent person. They are not really a director or exec but they often act like it and seem immune from any repercussions from the actual higher ups. This person tends to attract "followers" that know they will keep their…

I tried my best to offer a pragmatic recommendation for dealing with those sorts of people. I'd love to know what you would recommend instead?

IME it's politics, so you need to find someone that the sticky person fears/respects, and get them onboard.

The only other way I have succeeded is to appeal to the sticky person's ego, make them think that it's their idea.

Note: I have also had to deal with

Sticky person: Do it this way

Me: But X

Sticky Person: No, do it the way I have decreed

[...]

Three hours later (literally)

Sticky Person: Do it X way

Re: Mistakes engineers make in large established codebases

#162

Post by __MatrixMan__ » Wed, Jan 08, 2025, 4:22 AM UTC

hnthrow90348765 wrote: post #143

__MatrixMan__ wrote: post #116

Earlier quoted context omitted.

Would you be willing to put that take on your LinkedIn profile? If not... well that's why.

Remembering a controversial take over the code produced/improved is evidence to me that the matter is not settled that we should be spending the extra effort to align our practices with the article. The incentives are not there.

Of course it's not settled. It's awful (the code, not the article). It was written at a time when they didn't know better. Now they do, but they need somebody to maintain it anyway.

> Do you eventually put up with enough legacy mess, pay your dues, then graduate to the clean and modern code bases?

Yeah, that's called retirement. The point of the article isn't that whatever you're conforming to in the legacy codebase is worth preserving. The point is that whatever hell it is, it'll be a worse hell if you make it an inconsistent one.

Re: Mistakes engineers make in large established codebases

#163

Post by dml2135 » Wed, Jan 08, 2025, 4:28 AM UTC

rudasn wrote: post #58

Cthulhu_ wrote: post #35

Earlier quoted context omitted.

And that's a fair criticism, however, if you change a pattern without changing it everywhere, you now have two patterns to maintain (the article mentions this). And if multiple people come up with multiple patterns, that maintenance debt multiplies. Progress and improvement is fine, great even, but consistency is more important. If you change a pattern, change it everywhere.

Change it at once everywhere on an existing large codebase? That's going to be one huge PR no one will want to review properly, let alone approve. Document the old pattern, document the new pattern, discuss, and come up with a piece by piece plan that is easy to ship and easy to revert if you do screw things up. Unless the old pattern is insecure or burns your servers, that is.

I don’t think you and the comment you are replying to are in conflict. Documenting and rolling it out piecemeal is the correct way to make a large change.

I think the point is, either actually commit to doing that, or don’t introduce the new pattern.

Re: Mistakes engineers make in large established codebases

#164

Post by rf15 » Wed, Jan 08, 2025, 4:31 AM UTC

> Single-digit million lines of code (~5M, let’s say)

as someone working on a 60M codebase, we have very different understandings of the word "large". My team is leaning more towards "understand the existing code, but also try to write maintainable and readable code". Everything looks like a mess built by a thousand different minds, some of them better and a lot of them worse, so keeping consistency would just drag the project deeper into hell.

Re: Mistakes engineers make in large established codebases

#165

Post by [deleted] » Wed, Jan 08, 2025, 4:35 AM UTC

bryanrasmussen wrote: post #147

liontwist wrote: post #126

Earlier quoted context omitted.

This is totally fine. If you're given shit data this seems like a reasonable way to try to parse it (I would personally bound the loop). Typescript is not going to make it better. The problem is whoever is producing the data.

I think the complaint here is they have a string, which even has the word string in the variable name, and they turn it into an object at the end. Hence references to Typescript. I suppose what is wanted is something like let parsedJSON = {} try { parsedJSON = JSON.parse(susJsonString) } catch { //maybe register problem with parsing. }

[deleted]

Re: Mistakes engineers make in large established codebases

#166

Post by duskwuff » Wed, Jan 08, 2025, 4:36 AM UTC

Cthulhu_ wrote: post #52

gwbas1c wrote: post #22

One thing I did was implement a code formatter, and enforce it in CI. "dotnet format" can do wonders, and solved most serious inconsistency issues.

Honestly Go's approach to code formatting and it being taken over by other parties has saved so much trivial debates. I remember spending stupid amounts of review comments on stupid shit like formatting, trailing commas, semicolons, spacing, etc that should have been spent on more important things. How come automatic, standardized, non-ide bound automatic formatting has only been a thing in the past decade or so? I d…

> How come automatic, standardized, non-ide bound automatic formatting has only been a thing in the past decade or so?

A lot of it boils down to "because the people writing code parsers/lexers weren't thinking about usability". Writing a C formatter, for example, depends on having a parser that doesn't behave like a compiler by inlining all your include files and stripping out comments. For a long time, writing parsers/lexers was the domain of compiler developers, and they weren't interested in features which weren't strictly required by the compiler.

Another effect of those improvements, incidentally, has been higher quality syntax errors.

Re: Mistakes engineers make in large established codebases

#167

Post by Tknl » Wed, Jan 08, 2025, 4:51 AM UTC

noodletheworld wrote: post #145

hnanon98791 wrote: post #130

> 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 > The cardinal mistake is inconsistency Funny enough, the author notes the problem on why consistency is impossible in such a project and the proceeds to call it the cardinal mistake. You cannot be consistent in a project of…

> people like to use new language features and frameworks. Have of the point of this article is that people need to suck it up and not use new frameworks sometimes... There are times for coding in a way you, personally, find pleasing; and there are times when: > So you should know how to work in the “legacy mess” because that’s what your company actually does. Good engineering or not, it’s your job. A quote from the…

I've successfully pulled off most of such a majority re-write but a key driver - but not the only was that the legacy language the existing system was implemented in had lost virtually all traction in the local and global market. Mostly only expensive contractors coming out of pension availabile and on top of that the custom libraries required us to recruit the 10 percent of that segment. Any new hires straight up refused to pick it up as they accurately deemed it career suicide.

Re: Mistakes engineers make in large established codebases

#168

Post by StellarScience » Wed, Jan 08, 2025, 4:57 AM UTC

sfink wrote: post #138

peterldowns wrote: post #34

I agree that consistency is important — but what about when the existing codebase is already inconsistent? Even worse, what if the existing codebase is both inconsistent and the "right way to do things" is undocumented? That's much closer to what I've experienced when joining companies with lots of existing code. In this scenario, I've found that the only productive way forward is to do the best job you can, in your…

Hopefully, you have a monorepo or something with similar effects, and a lack of fiefdoms. In that case, if the current way is undocumented and/or inconsistent, you make it better before or while adding in your new approach. If there are 4 ways to do the same thing and you really want to do it a different way, then replace one of those ways with your new one in the process of adding it. For extra credit, get to the po…

Great points, I'd just add:

> A lot of inconsistency is the result of unwillingness to fix other people's stuff

Agree, so we find it best to practice "no code ownership" or better yet "shared code ownership." So we try to think of it all as "our stuff" rather than "other people's stuff." Maybe you just joined the project, and are working around code that hasn't been touched in 5 years, but we're all responsible for improving the code and making it better as we go.

That requires a high trust environment; I don't know if it could work for Firefox where you may have some very part-time contributors. But having documented standards, plus clang-format and clang-tidy to automate some of the simpler things, also goes a long way.

Re: Mistakes engineers make in large established codebases

#169

Post by Animats » Wed, Jan 08, 2025, 5:06 AM UTC

> 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 authors are long gone. Doing anything requires reverse engineering something. Learning the code base is time-consuming. It may be a year before someone new is productive.

Such a job may be a bad career move. You can spend a decade learning a one-off system, gaining skills useless in any other environment. Then it's hard to change jobs. Your resume has none of the current buzzwords. This helps the employer to keep salaries down.

Re: Mistakes engineers make in large established codebases

#170

Post by riwsky » Wed, Jan 08, 2025, 5:09 AM UTC

Sounds like common law—one of the biggest, oldest "codebases" there is.

To quote Wikipedia:

> Common law is deeply rooted in stare decisis ("to stand by things decided"), where courts follow precedents established by previous decisions.[5] When a similar case has been resolved, courts typically align their reasoning with the precedent set in that decision.[5] However, in a "case of first impression" with no precedent or clear legislative guidance, judges are empowered to resolve the issue and establish new precedent.