196
Your Engineers Aren't Lazy, Your Codebase Is Punishing Them (piechowski.io)
submitted 7 months ago by to c/programming@programming.dev
62 comments fedilink hide all child comments
 

A client’s team spent a full week adding a CSV export to their admin panel. Two engineers, clear requirements, maybe a day of actual work. The rest of the time went to understanding existing code well enough to change it safely. That’s what I call codebase drag: when the codebase makes every task take longer than it should. It doesn’t show up in any dashboard or sprint report.

you are viewing a single comment's thread
view the rest of the comments
[–] 11 points 7 months ago (8 children)

Anything that makes the codebase harder to maintain than it should be is technical debt.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 2 points 7 months ago* (7 children)

    Whilst true, I was not talking about maintenance...

    Rather "getting started in" ie onboarding.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 3 points 7 months ago (6 children)

    “How easy is it to onboard?” is functionally equivalent to “How easy is it to understand?”. The biggest factor in maintainability almost always boils down to how easy it is to understand. So, difficult to onboard almost certainly means difficult to maintain, and thus is tech debt.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 0 points 7 months ago (5 children)

    I see that as too idealist. When the rubber hits the road you cant spoon feed every newcomer with 100x docs per 1x code, so it's inevitably going to be difficult for some to approach.

    So now cos it's hard for somebody you assume there is debt?... It can't be infinitely easy.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 7 months ago (4 children)

    If your project is easy to maintain (aka low tech debt) that means it should be easy to understand the overall structure and it should be easy to understand any given component. So a new dev should be able to quickly figure out what part they need to change and how to change that part.

    Some large, complex systems (like an OS) are unavoidably complex. Maybe it’s not fair to call that tech debt, but it’s still functionally the same thing - stuff that slows down development velocity due to difficulty of understanding. It’s just (probably) unavoidable given the domain.

    But the majority of software projects aren’t that complex. The majority of software is apps and libraries that aren’t terribly complex. Monsters like operating systems and million to billion user scale products are outliers.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 7 months ago (3 children)

    So did we make it to "codebase drag" yet?

    Something that isn't debt but is a headwind to making changes.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 7 months ago (2 children)

    If we’re talking about the Linux kernel or Netflix’s video delivery infrastructure, maybe. But the majority of developers are not working on those. And I’m still going to call it “unavoidable technical debt” because for all intents and purposes that’s what it is.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •