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

351–360 of 384 posts

Re: Mistakes engineers make in large established codebases

#351

Post by 59nadir »

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?

Only in the sense that you seem to not understand how terrible big companies, big teams and big code bases are for efficiency and productivity. It pushes the bar for reaching desired results way up, and the time it takes to get there even more. No one should ever want to be part of organizations, teams or code bases like this, for their own sake.

Re: Mistakes engineers make in large established codebases

#352

Post by bryanrasmussen »

accoil wrote: post #244
bryanrasmussen wrote: post #201

Earlier quoted context omitted.

Hmm, yeah ok, didn't pick this out of the let susJsonString = '...' example but evidently it is not just that it is serialized multiple times, otherwise it shouldn't need the try catch (of course one problem with online discussion of code examples is you must always assume, contra obvious errors, that the code actually needs what it has) Something upstream, sure, but often not something "fixable" either, given third…

Yeah. I imagine that's a bandaid around having to consume a dodgy api that they didn't have access/permission to fix. The blanket catch is odd though, as I'd have thought that it would still be outputting valid json (even if it has been serialized multiple times), and if you're getting invalid json you probably want to know about that.

probably some times the api comes out with an empty string.

Re: Mistakes engineers make in large established codebases

#353

Post by bitcraft »

bricestacey wrote: post #291
Kinrany wrote: post #212

Earlier quoted context omitted.

Do you think boyscouting, "leave it better than you found it" is misguided as well?

I do not believe in "boyscouting". I think if you want to leave it better, make a ticket and do it later. Tacking it on to your already planned work is outside the scope of your original intent. This will impact your team's ability to understand and review your changes. Your codebase is unlikely to be optimized for your whimsy. Worse though is when a reviewer suggests boyscouting. I've seen too many needless errors a…

Boyscouting works because you don’t need to get permission to fix tech debt when it is bundled with something else. 98% of those tickets you file to fix warts will never be addressed because the business demands that time is spent on features that make money.

Re: Mistakes engineers make in large established codebases

#354

Post by teeray »

ge96 wrote: post #19

I'm just thinking about this time at a previous job, I was reviewing a PR and they decided to just find/replace every variable and switch from snake to camel case. I was like "why are you guys doing this, not part of the job". There was some back and forward on that. This is a place where PRs weren't about reviews but just a process to follow, ask someone to approve/not expect feedback. edit: job = ticket task

For stuff like this, the best thing is to have a style guide. If you disagree with something in the style guide (tabs/spaces, casing, etc.), you make a PR to the style guide and hash it out there. Also, those PRs need updates everywhere to make the codebase agree with the change and updates to relevant linters enforce it.

Outside of that, the style guide is law.

Re: Mistakes engineers make in large established codebases

#355

Post by aleph_minus_one »

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…

> If you do that, it might turn into "you were the engineer".

The correct solution would of course rather be "you were the manager". :-(

Re: Mistakes engineers make in large established codebases

#356

Post by niels_bom »

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.

Expecting a developer with 4 YoE to be able to handle a messy legacy codebase by themselves is a suboptimal business decision I’d say.

Re: Mistakes engineers make in large established codebases

#357

Post by niels_bom »

post-it wrote: post #271
sfink wrote: post #138

Earlier quoted context omitted.

Hopefully, you have a monorepo or something with similar effects, and a lack of fiefdoms. In that case, if the current way is undocumented and/or inconsistent, you make it better before or while adding in your new approach. If there are 4 ways to do the same thing and you really want to do it a different way, then replace one of those ways with your new one in the process of adding it. For extra credit, get to the po…

> In that case, if the current way is undocumented and/or inconsistent, you make it better before or while adding in your new approach. Sometimes, but oftentimes that would involve touching code that you don't need to touch in order to get the current ticket done, which in turn involves more QA effort.

The need is quite widely interpretable though.

I worked on a Drupal site once where somebody had put business logic and database querying inside of template files.

Just because you can implement something without touching any other part of the codebase doesn’t mean that’s a good decision.

Re: Mistakes engineers make in large established codebases

#358

Post by niels_bom »

aleph_minus_one wrote: post #139
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.

> I believe that most engineers want to write good code But the opinion what makes code good differ a lot between software developers. This exactly leads to many of the inconsistencies in the code.

And that’s why you talk about it and agree on stuff. I call that being a professional.

Re: Mistakes engineers make in large established codebases

#359

Post by [deleted] »

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.

[deleted]

Re: Mistakes engineers make in large established codebases

#360

Post by [deleted] »

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.

[deleted]
Post reply on HN