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

331–340 of 384 posts

Re: Mistakes engineers make in large established codebases

#331

Post by cwalv »

peterarmstrong wrote: post #327
cwalv wrote: post #287

Earlier quoted context omitted.

> I'd love to work in a fantasy company that allows for fixing legacy code You're not supposed to ask. It's like a structural engineer asking if it's okay to spend time doing a geological survey; it's not optional. Or a CFO asking if it's okay to pay down high interest debt. If you're the 'engineer', you decide the extent it's necessary

No. You discuss it with your manager, and you do it at the appropriate time. Having both created, refactored and deleted lots of technical debt over the past 25 years, trust me: you just don't get to go rogue because "you're the engineer". If you do that, it might turn into "you were the engineer". What if you spend a week or month refactoring something that needs a quick fix now and is being deleted in 1-2 years? Th…

> No. You discuss it with your manager, and you do it at the appropriate time.

Sure, if you're not sure if it's the right thing to do, talk to your manager or TL. A good engineering manager can help. If your manager "would never allow" it, they're not a good manager. Even for jobs much more menial than engineering, a good manager recognizes that autonomy/trust are critical for satisfaction and growth.

If you're working someplace where you're "not allowed" to make the changes you "wish you could," you're doing yourself a disservice. Find someplace where you're not only "allowed," but expected to have (or develop) the judgement required to make these decisions.

To be clear: "the business" expects (and in the medium/long term requires) engineers to make these decisions themselves. That is the job

Re: Mistakes engineers make in large established codebases

#332

Post by ozim »

Problem with consistency is that people miss forest for the trees.

So lots of nitpicking on irrelevant stuff - keep files under 50 lines - that is silly consistency of little minds.

Author of the post fortunately writes from experience perspective with architectural examples so I ca write that it is good article.

Re: Mistakes engineers make in large established codebases

#333

Post by liontwist »

darepublic wrote: post #326
liontwist wrote: post #252

Earlier quoted context omitted.

You came in so confident it was wrong, but it turns out you don’t really know what it does. Please take a lesson from this. Good code is not the one that follows all the rules you read online. Your coworker you dismissed understood the problem.

I didn't know that JSON.stringify could be called multiple times on the same object and then unpacked via repeated calls to JSON.parse. So I was wrong on that. I think definitely this warrants a comment in the code, at the least explaining why this was taking place. The likely reason for the nesting was I think calling an LLM for a valid json object and somewhere in that workflow the json object was getting stringifi…

So no lessons learned?

Re: Mistakes engineers make in large established codebases

#335

Post by valzam »

During my last job I have formulated what for me are the 2 unquestionable metrics to care about when trying to build long-term maintanable systems:

- Consistency (fully agree with the article here)

- Control

Control to me means that you have to work extremely hard to lose the ability to change the parts you care about. For example:

- Do not leak libraries and frameworks far into your business logic. At some point you want to introduce a new capabilty but say the class/type you re-used from a library makes it really awkward. Now you are faced with a huge refactor. The more logic, the purer and simpler the code should be. Ideally stdlib only.

- Do not build magic, globally shared test harnesses. Helpers yes, but if you give up control over the environment a test runs is / setting up fixtures, test data etc. you will run into a world of pain due to dependencies between tests and especially the test data.

- Do not let libraries dictate your application architecture. E.g. I always separate the web framework layer (controllers, views etc.) from the service and data layers.

- Consistency plays a major part here. If you introduce 3 libraries to do the same thing you have basically given up control over that dependencies and refactors in the future will be much harder.

Re: Mistakes engineers make in large established codebases

#336

Post by dennis_jeeves2 »

newaccountman2 wrote: post #135
mjr00 wrote: post #17

> The other reason is that you cannot split up a large established codebase without first understanding it. I have seen large codebases successfully split up, but I have never seen that done by a team that wasn’t already fluent at shipping features inside the large codebase. You simply cannot redesign any non-trivial project (i.e. a project that makes real money) from first-principles. This resonates. At one former c…

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

Yes.

Re: Mistakes engineers make in large established codebases

#337

Post by vimax »

valzam wrote: post #335

During my last job I have formulated what for me are the 2 unquestionable metrics to care about when trying to build long-term maintanable systems: - Consistency (fully agree with the article here) - Control Control to me means that you have to work extremely hard to lose the ability to change the parts you care about. For example: - Do not leak libraries and frameworks far into your business logic. At some point you…

I lump those together into what I call Dependency-Driven Development. Manage and reduce dependencies first, both external dependencies and internal dependencies within code, and better code will follow.

It's not always 100%, but in general the fewer the dependencies the better the code.

Re: Mistakes engineers make in large established codebases

#338

Post by jongjong »

jimbokun wrote: post #132
jongjong wrote: post #56

I'm now working on a codebase which is quite large (13 micro-services required to run the main product); all containerized to run on Kubernetes. The learning curve was quite steep but luckily, I was familiar with most of the tech so that made it easier (I guess that's why they hired me). The project has been around for over 10 years so it has a lot of legacy code and different repos have different code styles, engine…

If you can’t change, test and deploy each service independently from the others, you don’t really have separate services. You just have a Ball of Mud held together with HTTP calls.

We can test and change them independently, some features just require changing just one repo but most features affect multiple repos. But yes, essentially, it's a ball of mud in our case anyway because the separation between the two most important microservices is unclear (cannot be explained simply, there is no clear logic/responsibility separation besides the fact that one is an older codebase and the other is newer).

I've worked on a lot of projects in my career and this one has one of the most complex/chaotic architectures I've seen yet. Surprisingly, it recovers from service downtimes and reboots pretty well. The main issues are maintainability, deployment and configuration. It's often the case that local env does not match staging when building features.

Re: Mistakes engineers make in large established codebases

#339

Post by eru »

Supermancho wrote: post #272
eru wrote: post #112

Earlier quoted context omitted.

I feel your pain. But I guess you need to work harder on detecting these kinds of work places upfront, instead of joining them one after another?

Generally, companies filter out candidates who request to look at any measurable amount of source code as part of the process. Larger companies leveragethe 6-12 mo contractor to hire. You are still stuck there until you are not. These topics are common knowledge, if you have interviewed in the last 5 to 10 years. I have been working for 25, so I find the blame trying to be redirected, by some, misguided.

Yes, you can't directly look at the source code (unless you pick companies that open source a lot). But I was more thinking of trying to develop some proxy metrics that you can measure; the most common being asking the right questions in the interview. But you can also try to look for other tells.

Re: Mistakes engineers make in large established codebases

#340

Post by lmm »

devnullbrain wrote: post #235
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…

>making your little corner of the codebase nicer than the rest of it is fine, actually As TFA points out, you might find out that you've made your little corner worse, actually.

I don't think the examples add up. Like, yes, if the system has a way to do auth then you should use it. But if the system's way of doing auth has nasty surprises, rather than cargo-cult the workaround to those nasty surprises, you should fix them! (Especially if the article wants to argue that adding inconsistency is bad - then by the same token removing the inconsistency that someone added before you is good). And if the system has its own custom auth implementation that does the same thing as a standard library, you should probably pull it out completely and replace it with that standard library.
Post reply on HN