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

371–380 of 384 posts

Re: Mistakes engineers make in large established codebases

#371

Post by devnullbrain »

lmm wrote: post #340
devnullbrain wrote: post #235

Earlier quoted context omitted.

>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…

That's the wrong model for the example. Some nasty surprises are derived from real world complexity. Imagine something like a timezone library.

Also:

>you should fix them!

OK, great! See you in 10 years when you've fixed everything and are ready to start implementing stakeholder requirements.

Re: Mistakes engineers make in large established codebases

#373

Post by yid »

tuyiown wrote: post #234
yid wrote: post #195

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? Bluntly, yes. And so is every other reply to you that says "no this isn't naive", or "there's no reason this project shouldn't have finished". All that means is that you've not seen a truly "enterprise" codebase that may be bringing in tons of business value, but whos…

If you find me any resources to build access control on arbitrary (I mean it, arbitrary) rules the right way, I would be very very (very) glad.

I think that's just called "code".

Re: Mistakes engineers make in large established codebases

#374

Post by throwaway2037 »

hinkley wrote: post #300
staunton wrote: post #200

Earlier quoted context omitted.

> A bridge that is missing support probably wouldn't have been opened to the public in the first place. That's not always been the case and came to be because people have died... Is anyone going to die if your codebase is an unmaintainable mess?

Companies die because nobody is willing to work on the code anymore. If VCs ever came to expect less than 90% of their investments to essentially go to zero, maybe that would change. But they make enough money off of dumb luck not leading to fatal irreversible decisions often enough to keep them fat and happy.

    > Companies die because nobody is willing to work on the code anymore.
Can you name some examples? I never heard of this before.

Re: Mistakes engineers make in large established codebases

#375

Post by throwaway2037 »

zwnow wrote: post #316
hansvm wrote: post #275

Earlier quoted context omitted.

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.

    > I barely have 4 years of experience so I really really dont have the time to fix shit.
I am confused. In my first few years of my career, I did lots of refactoring because it helped me to learn different codebases and learn the skill of refactoring. Your experience is somewhat unrelated to your ability to fix old code. Desire is required.

Re: Mistakes engineers make in large established codebases

#376

Post by erikpukinskis »

baq wrote: post #186
zwnow wrote: post #183

Earlier quoted context omitted.

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…

> The issue is that management usually doesn't care. Neither do customers. The product is an asset. Code is a liability.

Well engineered code that closely models the business is an asset.

Only a small percentage of code that’s ever written matches that criteria.

That asset also requires you to have good relationships with people who know how to maintain it properly.

Re: Mistakes engineers make in large established codebases

#377

Post by tremon »

whatevaa wrote: post #370
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

Totally no. Structural engineers also have to consider real life constraints, including cost. We are talking about working with existing structures, it's too late for geological surveys.

That totally depends on the surrounding configuration. If land subsidence was as common as security patches, they would totally be doing monthly surveys.

Structural engineers also don't commonly change structural features after initial delivery; realistically, I would expect changing a two-lane bridge to a four-lane bridge to be more expensive than constructing a four-lane bridge where none exists.

Re: Mistakes engineers make in large established codebases

#378

Post by tremon »

zwnow wrote: post #315
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

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…

The Linux kernel is a multi-million line codebase, and refactoring still happens when needed. Let's not extrapolate from your limited data points as if they are representative for all codebases.

Re: Mistakes engineers make in large established codebases

#379

Post by nadis »

A little buried since the overarching focus is on consistency but I found these two paragraphs from the blog post really relevant points as well:

"You need to develop a good sense of how the service is used in practice (i.e. by users). Which endpoints are hit the most often? Which endpoints are the most crucial (i.e. are used by paying customers and cannot gracefully degrade)? What latency guarantees must the service obey, and what code gets run in the hot paths? One common large-codebase mistake is to make a “tiny tweak” that is unexpectedly in the hot path for a crucial flow, and thus causes a big problem.

You can’t rely on your ability to test the code in development like you can in a small project. Any large project accumulates state over time (for instance, how many kinds of user do you think GMail supports?) At a certain point, you can’t test every combination of states, even with automation. Instead, you have to test the crucial paths, code defensively, and rely on slow rollouts and monitoring to catch problems."

Re: Mistakes engineers make in large established codebases

#380

Post by citizenpaul »

Rastonbury wrote: post #283
citizenpaul wrote: post #109

Earlier quoted context omitted.

>and it's fine, right? The hard part of being an engineer is realizing that sometimes even when something is horribly wrong people may not actually want it fixed. I've seen systems where actual monetary loss was happening but no one wanted it brought to light because "who gets blamed"

That's crazy, is there no opportunity to get credit for preventing monetary loss?

I've been somewhere that no there was no rewards for fixing monetary loss. However thats not really what I was getting at, I was more hinting at embezzlement going on at LOTS of places.
Post reply on HN