Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mistakes engineers make in large established codebases

seangoedecke.com

Post reply on HN
Print view View original

121–130 of 384 posts

Re: Mistakes engineers make in large established codebases

#121

Post by stickfigure »

mrkeen wrote: post #23

There was only one mistake that the article felt like giving a header to: "The cardinal mistake is inconsistency" The instinct to keep doing things the wrong way because they were done the wrong way previously is strong enough across the industry without this article. I love to > take advantage of future improvements. However, newer and better ways of doing things are almost invariably inconsistent with the establish…

You will find someday that you'd rather have tests that are comprehensive rather than tests that are fast. Especially when a significant portion of your program logic is in sql statements.

Re: Mistakes engineers make in large established codebases

#122

Post by darepublic »

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.

doing some recent contract work I discovered someone putting this into a PR (comments my own)

```

let susJsonString = '...' // we get this parseable json string from somwhere but of course it might not be parseable. so testing seems warranted...

try { // lets bust out a while loop!

while(typeof susJsonString === 'string') { susJsonString = JSON.parse(susJsonString) }

} catch { susJsonString = {} }

// also this was a typescript codebase but all the more reason to have a variable switch types! this dev undoubtedly puts typescript at the top of their resume

```

I suppose this works?! I haven't thought it through carefully, it's just deciding to put your shoes on backward, and open doors while standing on your head. But I decided to just keep out of it, not get involved in the politics. I guess this is what getting old is like seriously you just see younger people doing stuff that makes your jaw drop from the stupidity (or maybe its just me) but you can't say anything because reasons. Copilot, ai assisted coding only further muddies the waters imo.

Re: Mistakes engineers make in large established codebases

#123

Post by jimbokun »

lmm wrote: post #103

I've worked in codebases like this and disagree. Consistency isn't the most important, making your little corner of the codebase nicer than the rest of it is fine, actually, and dependencies are great - especially as they're the easiest way to delete code (the article is right about the importance of that). What's sometimes called the "lava layer anti-pattern" is actually a perfectly good way of working, that tends t…

Pulling in lots of dependencies will eventually grind progress on features to a halt as you spend more and more time patching and deploying vulnerabilities. The probability of seeing new vulnerabilities I believe is pretty much linear in the number of dependencies you have.

Re: Mistakes engineers make in large established codebases

#124

Post by lamontcg »

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…

It is terrible to just do this on your own, particularly as the n00b.

If there are 5 different standards in the codebase, don't just invent your own better way of doing things. That is literally the xkcd/Standards problem. Go find one of the people who have worked there the longest and ask which of the 5 existing standards are most modern and should be copied.

And as you get more experience with the codebase you can suggest updates to the best standard and evolve it. The problem is that you then need to own updating that whole standard across the entire codebase. That's the hard part.

If you aren't experienced enough with the codebase to be aggressive about standardization, you shouldn't be creating some little playground of your own.

Re: Mistakes engineers make in large established codebases

#125

Post by jimbokun »

SoftTalker wrote: post #7
IvyMike wrote: post #3

The "The cardinal mistake is inconsistency" is 100% true. We used to call the guiding philosophy of working in these codebases "When in Rome".

Yep when I have to work on old code I find something in the existing code that's close to what I want to do, and copy/paste it. I do not try to abstract it into a common function, unless that's already been done and can be used verbatim. You don't know the 10 years of reasons behind why the code is the way it is, and the safest thing is to stay as close as possible to how the existing code is written, both to avoid l…

The only time I abstract something into a function even if it’s only used in one place, is if the generic case is as easier or easier than the code for the specific case.

But that’s a judgment call based on experience.

Re: Mistakes engineers make in large established codebases

#126

Post by liontwist »

darepublic wrote: post #122
peterldowns wrote: post #72

Earlier quoted context omitted.

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.

doing some recent contract work I discovered someone putting this into a PR (comments my own) ``` let susJsonString = '...' // we get this parseable json string from somwhere but of course it might not be parseable. so testing seems warranted... try { // lets bust out a while loop! while(typeof susJsonString === 'string') { susJsonString = JSON.parse(susJsonString) } } catch { susJsonString = {} } // also this was a…

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.

Re: Mistakes engineers make in large established codebases

#127

Post by liontwist »

Supermancho wrote: post #101
dasil003 wrote: post #98

Earlier quoted context omitted.

Yeah 100%. Honestly style / technique / language consistency are implementation details, it helps with engineer fungibility and ramp up, but it also works against engineers applying local judgement. This is something to briefly consider when starting new services/features, but definitely not something to optimize for in an existing system. On the other hand, data and logic consistency can be really important, but you…

A common experience (mostly in the Pacific North West) I have had is to implement a feature in a straightforward manner that works with minimal code, for some backlog issue. Then I'm told the PR will be looked at. A couple days later I am told this is not the way to do X. You must do it Y? Why Y? Because of historical battles won and lost why, not because of a specific characteristic. My PR doesn't work with Y and it…

This sounds like you are missing important context. Here is a similar conversation:

"Why do I have to use the system button class. I implemented my own and it works."

"Because when the OS updates with new behavior your button may break or not get new styling and functionality"

"But this works and meets the spec, that's 10x harder"

Re: Mistakes engineers make in large established codebases

#128

Post by jimbokun »

viraptor wrote: post #53
layer8 wrote: post #30

Earlier quoted context omitted.

How do you tackle the case where the codebase is consistent in a bad way, like pervasive use of antipatterns that make code difficult to change or to reason about? If you want to improve that, you have to start somewhere. Of course, Chesterton’s Fence applies.

Or when people keep the old pattern because there's a "higher priority". I've worked on a project with absolutely terrible duplication of deserialisers of models, each one slightly different even those most properties were named the same and should've been handled the same. But we can't touch anything because important things are happening in business and we can't risk anything. The ignored part was that this led to…

In the past I have performed needed refactorings as part of new feature development, without asking permissions. Even though my boss at the time said “don’t make it pretty, just make it work.”

Of course, I knew that writing the code the “pretty”, more maintainable, easier to understand way wouldn’t take any longer to write, and might take less time as the refactoring requires less new code overall.

But I didn’t bother explaining all that. Just nodded then went and implemented it the best way as I was the experienced software engineer.

Re: Mistakes engineers make in large established codebases

#129

Post by jimbokun »

tpoacher wrote: post #32
bdangubic wrote: post #18

Earlier quoted context omitted.

I also find amusing that “legacy” more often than not gets used in negative conotation. I hear “legacy” and I think “bunch of people wrote some AWESOME shit that lasted so long that now other people get to view it as ‘legacy’”

There's a good chance that's not what people mean by this term though. It's probably used in the (now) classic sense as defined by M. Feathers in his "Working with legacy code" book. Code that is old but otherwise awesome, maintainable (or even actively maintained) and easy / a joy to work with are rarely referred to as "legacy code".

It doesn’t seem awesome at first glance because it takes longer to get up to speed on a large, old code base than a small, young one.

But you will quickly learn how awesome the old code base is if you attempt to rewrite it, and realize everything the old code base takes into account.

Re: Mistakes engineers make in large established codebases

#130

Post by hnanon98791 »

> 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 that size and scope. Full stop. Half those engineers will statistically be below average and constantly dragging the codebase towards their skill level each time they make a change. Technology changes a lot in ten years, people like to use new language features and frameworks.

And the final nail in the coffin: the limits of human cognition. To be consistent you must keep the standards in working memory. Do you think this is possible when the entire project is over a million LOC? Don't be silly.

There's a reason why big projects will always be big balls of mud. Embrace it. http://www.laputan.org/mud/

Post reply on HN