Mistakes engineers make in large established codebases

Post by baq » Wed, Jan 08, 2025, 7:19 AM UTC

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?

Post by mrkeen » Wed, Jan 08, 2025, 7:25 AM UTC

jimbokun wrote: post #131

jrockway wrote: post #33

Earlier quoted context omitted.

I like keeping things consistent even if the consistent way is "wrong". One thing that bugged me about the large codebase I most recently worked on is that we used a custom assert library for tests. The Go team says this about them: https://go.dev/wiki/TestComments#assert-libraries , and having learned Go at Google, I would never have been allowed to check in code like that. But this place wasn't Google and there wer…

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.

Post by andrewf » Wed, Jan 08, 2025, 7:32 AM UTC

darepublic wrote: post #179

accoil wrote: post #159

Earlier quoted context omitted.

That's quite different though. It looks to be dealing with the case that a serialised object gets serialiased multiple times before it reaches that point of code, so it needs to keep deserialising until it gets a real object. E.g: JSON.parse(JSON.parse("\"{foo: 1}\"")) I'd guess the problem is something upstream.

The code is either going to loop once and exit or loop forever no

  let susJsonString=JSON.stringify(JSON.stringify(JSON.stringify({foo:1})))
  console.log("initial:", susJsonString);
  try { 
    while(typeof susJsonString==='string') {
        susJsonString = JSON.parse(susJsonString);
        console.log("iteration:", typeof susJsonString, susJsonString);
    }
  } catch {
    susJsonString = {};
  }

  initial: "\"{\\\"foo\\\":1}\""
  iteration: string "{\"foo\":1}"
  iteration: string {"foo":1}
  iteration: object {foo: 1}

Post by virgilp » Wed, Jan 08, 2025, 7:41 AM UTC

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…

Post by staunton » Wed, Jan 08, 2025, 7:47 AM 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…