Mistakes engineers make in large established codebases • Hacker News Board

Re: Mistakes engineers make in large established codebases

#311

Post by lamontcg » Wed, Jan 08, 2025, 6:19 PM UTC

peterldowns wrote: post #146

lamontcg wrote: post #124

Earlier quoted context omitted.

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…

> 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. I strongly disagree with you and believe you've missed the point of my comment. Think about this: why are there 5 different s…

> Do you think any engineers on the team are aware of this situation?

Yes, there probably are. If you haven't been working there for long enough to know who they are, then you shouldn't be YOLO'ing it.

The fact that it hasn't all been cleaned up yet is due to that being an order of magnitude harder than greenfielding your own standard. That doesn't mean that nobody is aware of it, or working on it.

I've absolutely worked for a decade on a codebase which had at least 5 different standards, and I was the one responsible for cleaning it all up, and we were understaffed so I could never finish it, but I could absolutely point you at the standard that I wanted you to follow. It also probably was somewhat deficient, but it was better than the other 4. It evolved over time, but we tried to clean it all up as we went along. Trying to ram another standard into the codebase without talking it over with me, was guaranteed to piss me off.

Re: Mistakes engineers make in large established codebases

#312

Post by bluGill » Wed, Jan 08, 2025, 6:21 PM UTC

potatolicious wrote: post #301

bluGill wrote: post #264

Earlier quoted context omitted.

I was involved with a big rewrite. Our manager had on his desk the old system with a sign "[managers name]'s product owner". Nearly every time someone wanted to know how to do something the answer was load that old thing up and figure out what it did. Eventually we did retire the old system - while the new code base is much cleaner I'm convinced it would have been cheaper to just clean that code up in place. It still…

> "I'm convinced it would have been cheaper to just clean that code up in place" Generally agreed. I'm generally very bearish on large-scale rewrites for this reason + political/managerial reasons. The trick with any organization that wants to remain employed is demonstrating progress. "Go away for 3 years while we completely overhaul this." is a recipe for getting shut down halfway through and reassigned... or worse…

Part of our issue with the rewrite is we went from C++ to C++. For an embedded system in 2010 C++ was probably the right choice (rust didn't exist, though D or Ada would have been options and we can debate better elsewhere). Previous rewrites went from 8 bit assembly to C++, which is the best reason to do a rewrite: you are actually using a different language that isn't compatible for an in place rewrite (D supports importing C++ and so could probably be done in place)

Re: Mistakes engineers make in large established codebases

#313

Post by franktankbank » Wed, Jan 08, 2025, 6:29 PM UTC

000ooo000 wrote: post #188

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?

You know so little about the team, the organisation, the codebase, other concurrent obligations (e.g. prod support), and the way the project is run. The only way I can imagine one having confidence in a statement like "nothing should take that long" is naïveté.

Then maybe 18 months wasn't too long and they should have been given more time. But seriously?

Re: Mistakes engineers make in large established codebases

#314

Post by franktankbank » Wed, Jan 08, 2025, 6:30 PM UTC

lkjdsklf wrote: post #280

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?

At a large enterprise, 6-9 months is blazingly fast. Everything takes longer than you think and this sounds like it involves at least 2 teams (the php team and the scalar team). Every team you include increases time line factorially in the best case. It takes a lot of time to have meetings with a dozen managers to argue over priority and whatever. Especially since their schedules are full of other arguments already

[flagged]

Re: Mistakes engineers make in large established codebases

#315

Post by zwnow » Wed, Jan 08, 2025, 6:57 PM UTC

cwalv wrote: post #287

zwnow wrote: post #180

Earlier quoted context omitted.

Thats not how software engineering works in a business setting though? Not a single company I have been in has the time to first fix the existing codebase before adding a new feature. The new feature is verbally guaranteed to the customers by project managers and then its on the dev to deliver within the deadline or you'll have much greater issues than a inconsistent codebase. I'd love to work in a fantasy company th…

> 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

Thats also not applicable in a business setting. If you have multi million line codebase, you simply cant refactor within reasonable time. Also refactoring can cause issues wich then need further fixing and refactoring.

If I touch code that I am not supposed to touch or that does not relate to my direct task I will have HR talks. I'd be lucky to not get laid off for working on things that do not relate to my current task.

Re: Mistakes engineers make in large established codebases

#316

Post by zwnow » Wed, Jan 08, 2025, 7:06 PM UTC

hansvm wrote: post #275

zwnow wrote: post #180

Earlier quoted context omitted.

Thats not how software engineering works in a business setting though? Not a single company I have been in has the time to first fix the existing codebase before adding a new feature. The new feature is verbally guaranteed to the customers by project managers and then its on the dev to deliver within the deadline or you'll have much greater issues than a inconsistent codebase. I'd love to work in a fantasy company th…

They don't think they have the time, but that's because they view task completions as purely additive. Imagine you're working on this or that feature, and find a stumbling block in the legacy codebase (e.g., a poorly thought out error handling strategy causing your small feature to have ripple effects you have to handle everywhere). IME, it's literally cheaper to fix the stumbling block and then implement the feature…

I am a solo dev for my company which is a semi profitable startup. Before I was hired the codebase was built by a hobbyist and remote workers. I was hired due to a language barrier with the remote staff. I barely have 4 years of experience so I really really dont have the time to fix shit. Currently I have to ship reckless without looking back. Thats upcoming tech companies for ya, will get worse with AI.

Re: Mistakes engineers make in large established codebases

#317

Post by zwnow » Wed, Jan 08, 2025, 7:10 PM UTC

cess11 wrote: post #305

zwnow wrote: post #197

Earlier quoted context omitted.

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.

I was in an organisation that made decent money on a system built on Laravel 3, I think. The framework was written in an only static classes style, which they over ten years had run with while building the business so everything was static classes. Once you have a couple of million lines of that, rewrite is practically impossible because you need to take the team of two OK devs and a junior off firefighting and featu…

I usually am in favor of a complete rewrite. I'd also prefer to not grow projects into multi million line monoliths. Just make multiple smaller ones that can interact independently with each other. Much simpler structure. Also safer in the long run.

Re: Mistakes engineers make in large established codebases

#318

Post by necovek » Wed, Jan 08, 2025, 7:27 PM UTC

zwnow wrote: post #183

huijzer wrote: post #181

Earlier quoted context omitted.

And then at some point the codebase becomes so unusable that new features take too long and out of frustration management decides to hire 500 extra programmers to fix the situation, which makes the situation even more slow. As I understand, there is a balance between refactoring and adding new features. It’s up to the engineers to find a way to do both. Isn’t it also fair if engineers push sometimes back on managemen…

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…

It depends.

Most shacks built in one's backyard do not pass any building codes. Or throwing a wooden plank over a stream somewhere.

Just like most software doesn't really risk anyone's life: the fact that your web site might go down for a bit is not at all like a bridge collapsing.

Companies do care about long term maintenance costs, and I've mostly been at companies really stressing over some quality metrics (1-2 code reviews per change, obligatory test coverage for any new code, small, iterative changes, CI & CD...), but admittedly, they have all been software shops (IOW, management understood software too).

Re: Mistakes engineers make in large established codebases

#319

Post by pavel_lishin » Wed, Jan 08, 2025, 7:42 PM UTC

zzbzq wrote: post #308

Wrong, wrong. Opposite of everything he said. All his examples are backwards. The article is basically inversing the Single Responsibility Principle. First of all, consistency does not matter at all, ever. THat's his main thesis so it's already wrong. Furthermore, all his examples are backwards. If you didn't know the existence of "bot" users, you probably don't want your new auth mechanism to support them. Otherwise…

> First of all, consistency does not matter at all, ever. THat's his main thesis so it's already wrong.

Can you say more about this? Because I strongly disagree with your assertion.

Re: Mistakes engineers make in large established codebases

#320

Post by veverkap » Wed, Jan 08, 2025, 8:13 PM UTC

pavel_lishin wrote: post #319

zzbzq wrote: post #308

Wrong, wrong. Opposite of everything he said. All his examples are backwards. The article is basically inversing the Single Responsibility Principle. First of all, consistency does not matter at all, ever. THat's his main thesis so it's already wrong. Furthermore, all his examples are backwards. If you didn't know the existence of "bot" users, you probably don't want your new auth mechanism to support them. Otherwise…

> First of all, consistency does not matter at all, ever. THat's his main thesis so it's already wrong. Can you say more about this? Because I strongly disagree with your assertion.

> Build stuff that does exactly what you want it to do, nothing more

This is also confusing to me. In a multi-million line codebase, it's extremely difficult to find an actual place where you have zero side effects with ANYTHING you write.