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

211–220 of 384 posts

Re: Mistakes engineers make in large established codebases

#211

Post by KronisLV »

olau wrote: post #210
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,…

But if you see yourself as trying to make the world a better place, you'll accept that because the large code base is actually doing a lot of good out there. The article discusses this at the end.

Sure, I can accept that, I'm not saying they're all bad, just that they have very obvious drawbacks, same as projects that pick untested technologies and get burned when they cease to exist after a year.

> Large codebases are worth working in because they usually pay your salary

Though remember that greenfield projects might also pay your salary and be better for your employability and enjoyment of your profession in some cases. They might be the minority in the job market, though.

Re: Mistakes engineers make in large established codebases

#212

Post by Kinrany »

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?

Re: Mistakes engineers make in large established codebases

#213

Post by quick_brown_fox »

I mostly agree, however experienced a different challenge exactly for the very reason of consistency:

I used to work within the Chromium codebase (at the order of 10s of million LOC) and the parts I worked in were generally in line with Google's style guide, i.e. consistent and of decent quality. The challenge was to identify legacy patterns that shouldn't be imitated or cargo-culted for the sake of consistency.

In practice that meant having an up to date knowledge of coding standards in order to not perpetuate anti-patterns in the name of consistency.

Re: Mistakes engineers make in large established codebases

#214

Post by lmm »

jimbokun wrote: post #171
abc-1 wrote: post #136

Earlier quoted context omitted.

As opposed to your in-house code which is vulnerability free? The issue isn’t vulnerability's, it’s dependency hell where all your packages are constantly fighting each other for specific versions. Although some languages handle this better than others.

In house code could very well have many fewer vulnerabilities, as you only write exactly the functionality you need, vs pulling a large dependency and only using a small percentage of the API.

> pulling a large dependency and only using a small percentage of the API.

This is normally a direct result of trying to limit the number of dependencies. People are much more able to use small, focused dependencies that solve specific problems well if you have a policy that permits large numbers of dependencies.

Re: Mistakes engineers make in large established codebases

#215

Post by sema4hacker »

I once did some contract work for a development group at Apple in the late 90's working on a product not yet released. It was the first time I was exposed to a large codebase that could be updated by any of a large number of programmers at any time. While investigating a bug, it was scary to constantly see large, complicated routines headed with one-line comments from 20 or 30 people logging the changes they had made. There would be no consistent style of code, no consistent quality, no consistent formatting, no real sense of ownership, a real free-for-all. The system not only immediately projected a sense of hopelessness, but also indicated that any attempts at improvement would quickly be clobbered by future sloppy changes.

Re: Mistakes engineers make in large established codebases

#216

Post by lmm »

praptak wrote: post #204

Another post from the same author puts this in an interesting context: https://www.seangoedecke.com/glue-work-considered-harmful/ (follow up: https://www.seangoedecke.com/cynicism/ ) Keeping the code base tidy is glue work, so you should only do enough of it to ship features. So maybe these are not "mistakes" but rather tactical choices made by politically smart engineers focused on shipping features.

Following management instructions against your better judgement is hardly uncynical - unless it's coming from a place of such naivety that you actually think you're wrong and they're right, and I don't think it is.

My experience is the opposite of the author's: in terms of their revealed preferences, line workers care far more about the company and its customers than managers and executives do, precisely because it's far easier for the latter to fail upwards than the former.

Re: Mistakes engineers make in large established codebases

#218

Post by physicsguy »

zwnow wrote: post #197
bcrosby95 wrote: post #187

Earlier quoted context omitted.

New features are the right time to refactor. If you can't make the code not complete shit you don't have time to add the feature. Never refactor code to make it prettier or whatever, refactor it when it becomes not-fit-for-purpose for what you need to do. There's obviously exceptions (both ways) but those are exceptions not rules. At least, that's what I teach our devs.

My company didn't even have time to keep the dependencies up to date so now we are stuck with Laravel 5 and Vue 2. Refactoring/Updating can be an incredible workload. Personally I'd say rewriting the whole thing would be more efficient but that's not my choice to make. If you have plenty of time for a task, I fully agree with you.

It's still also often the right business choice, especially for small businesses which aren't making a profit yet.

Re: Mistakes engineers make in large established codebases

#219

Post by ReflectedImage »

"as a general rule, large established codebases produce 90% of the value."

This is only until your new upstart competitor comes along, rewrites your codebase from scratch and runs you out of the market with higher development velocity (more features).

Re: Mistakes engineers make in large established codebases

#220

Post by physicsguy »

darepublic wrote: post #115
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…

My last experience with this, in the section of code I had to navigate for my first ticket at startup X we had some code that was querying the same tables multiple times unnecessarily. We were also using a highly bespoke (imo) code library with a relatively small following on github but this library permeated the entire codebase and dictated the way things had to be done. I tried to just make my changes by touching t…

I had this in 2018 with a company that were still using csh scripts in all of the development tooling.
Post reply on HN