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

271–280 of 384 posts

Re: Mistakes engineers make in large established codebases

#271

Post by post-it »

sfink wrote: post #138
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…

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.

Re: Mistakes engineers make in large established codebases

#272

Post by Supermancho »

eru wrote: post #112
Supermancho wrote: post #101

Earlier quoted context omitted.

A common experience (mostly in the Pacific North West) I have had is to implement a feature in a straightforward manner that works with minimal code, for some backlog issue. Then I'm told the PR will be looked at. A couple days later I am told this is not the way to do X. You must do it Y? Why Y? Because of historical battles won and lost why, not because of a specific characteristic. My PR doesn't work with Y and it…

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.

Re: Mistakes engineers make in large established codebases

#273

Post by david-gpu »

bluGill wrote: post #264
danjac wrote: post #245

Earlier quoted context omitted.

Often the problem with companies running the Feature Factory production treadmill too long is you have code supporting unused features and business logic, but nobody knows any more which features can be dropped or simplified (particularly after lots of employee churn and lack of documentation). So the problem is not so much technical debt, but product debt. You can refactor, but you're also wasting time optimizing co…

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…

> while the new code base is much cleaner I'm convinced it would have been cheaper to just clean that code up in place

I saw one big rewrite from scratch. It was a multi-year disaster, but ended up working.

I was also told about an earlier big rewrite of a similar codebase which was a multi-year disaster that was eventually thrown away completely.

I did see one big rewrite that was successful, but in this case the new codebase very intentionally only supported a small subset of the original feature set, which wasn't huge to begin with.

All of this to say that I agree with you: starting from scratch is often tempting, but rarely smooth. If refactoring in place sounds challenging, you need to internalize that a full rewrite will be a few times harder, even if it doesn't look that way.

Re: Mistakes engineers make in large established codebases

#274

Post by edanm »

lmm wrote: post #266
edanm wrote: post #251

Earlier quoted context omitted.

> No-one's actual business problem takes 5M lines of code to describe, those 5M lines are mostly copy-paste "patterns" and repeated attempts to reimplement the same thing. I'm pretty sure this is trivially untrue. Any OS is probably more than 5M lines (Linux - 27.8 lines according to a random Google Search). Facebook is probably more lines of code. Etc.

> Any OS is probably more than 5M lines (Linux - 27.8 lines according to a random Google Search). Linux is notoriously fragmented/duplicative, and an OS isn't the solution to anyone's actual business problem. A well-factored solution to a specific problem would be much smaller, compare e.g. QNX. > Facebook is probably more lines of code. IIRC Facebook is the last non-monorepo holdout among the giants, they genuinely…

I'm fairly sure Word, Excel, Google Sheets, Youtube, Photoshop, etc. all have fairly high counts.

As do many tens of thousands of applications that are the backbone of services we all rely on. The systems that run banks, that run power plants, the routers that make up the backbone of the internet, etc.

Again, I agree with some of the spirit of what you're saying... but there's also a tendency of many developers (like myself) to only think of shiny new products, or to only think about the surface-level details of most business problems. You write:

> So I mean yeah, on some level solving the business problem can take as many lines as you want it to, because it's always possible to add some special case enhancement for some edge case that takes more lines. But if you just keep growing the codebase until it's unprofitable then that's not actually particularly valuable code and it's not very nice to work on either.

I think this misunderstands how the companies that have stayed in business for so long have done so. Excel is the software we all use every day because it kept adding more and more features, stealing the best ideas from new products that tried to innovate. It's still doing so, though obviously to a lesser extent.

Re: Mistakes engineers make in large established codebases

#275

Post by hansvm »

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

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, especially when you factor in debugging down the line once some aspect of the kludgy alternative rears its ugly head. You're touching ten thousand lines of code anyway; you might as well choose do it as a one-off cost instead of every time you have to modify that part of the system.

That's triply true if you get to delete a bunch of code in the process. The whole "problem" is that there exists code with undesirable properties, and if you can remove that problem then velocity will improve substantially. Just do it Ship of Theseus style, fixing the thing that would make your life easier before you build each feature. Time-accounting-wise, the business will just see you shipping features at the target rate, and your coworkers (and ideally a technical manager) will see the long-term value of your contributions.

Re: Mistakes engineers make in large established codebases

#276

Post by Supermancho »

liontwist wrote: post #127
Supermancho wrote: post #101

Earlier quoted context omitted.

A common experience (mostly in the Pacific North West) I have had is to implement a feature in a straightforward manner that works with minimal code, for some backlog issue. Then I'm told the PR will be looked at. A couple days later I am told this is not the way to do X. You must do it Y? Why Y? Because of historical battles won and lost why, not because of a specific characteristic. My PR doesn't work with Y and it…

This sounds like you are missing important context. Here is a similar conversation: "Why do I have to use the system button class. I implemented my own and it works." "Because when the OS updates with new behavior your button may break or not get new styling and functionality" "But this works and meets the spec, that's 10x harder"

More like we have to use the god object to make all http calls for consistency in logging, despite this being a gcp pubsub.

Re: Mistakes engineers make in large established codebases

#277

Post by mrkeen »

jrockway wrote: post #172
jimbokun wrote: post #131

Earlier quoted context omitted.

I work on a service where a big percentage of the code is persisting to and reading from various stores, so unit tests have very limited value compared to integration tests.

Yeah, if you can start up the actual things, then you know your code's going to work against the actual things. That's ultimately what we're aiming for.

That's not sufficient.

The actual things are IO devices, and will sometimes fail and sometimes succeed. No judgement, just a fact of life.

I code my tests such that my logic encounters successes, timeouts, exceptions, thread-cancellations, etc. All at unit-test speed.

I can't trick an MSSQL deployment into returning me those results.

It doesn't take 30 seconds to test what your system will do in 30 seconds.

Re: Mistakes engineers make in large established codebases

#278

Post by ninalanyon »

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…

> common problem is devs trying to improve random things.

Been there, been guilty of that at the tail end of my working life. In my case, looking back, I think it was a sign of burnout and frustration at not being able to persuade people to make the larger changes that I felt were necessary.

Re: Mistakes engineers make in large established codebases

#279

Post by digging »

liontwist wrote: post #252
darepublic wrote: post #178

Earlier quoted context omitted.

Why the while loop

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.

Did you reply to the wrong comment?

I think asking questions is ideal. Even when I'm 99% sure a line is blatantly wrong, I will ask something like, "What is this for?". Maybe I missed something - wouldn't be the first time.

Re: Mistakes engineers make in large established codebases

#280

Post by lkjdsklf »

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?

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

Post reply on HN