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
[–] 69 points 7 months ago (20 children)

Oh hey, next sprint we’re going to work on that!

Oh, there’s a feauture request from sales you say? Hard due date of Thursday? But that’s a really big feature we can’t just… okay fine, but the next sprint we’re need to work on tech debt.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 20 child comments
    •
  • [–] 30 points 7 months ago

    When developing code for first release, we had a dedicated HIP Sprint (Hardening, Innovation, Planning) and we had the most productive team in the company. Other teams were struggling cause they were just using the HIP as another Sprint. So what did we do? Got rid of the HIP, naturally. You see, some teams weren't using it and it's unfair to those teams that we're not doing work when they are. Now everyone's suffering!

    Also had legitimate agile practices (budgets are for HR, work on what you need to work on and let someone else worry about paying for it) and we were the most productive team in the company. So, naturally, they need to get a bunch of C-suite guys to come over and run things cause it would be really embarrassing for them if they weren't involved in the new hotness. Naturally, though, we gotta go back to funding buckets, cause those c-suite guys don't understand why they got to talk to the developers when they want something fixed instead of handing things down from on high. Oh no! Suddenly all these issues are popping up in the workflow, guess we gotta force in ai to fix the problems.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 20 points 7 months ago (3 children)

    Last place I worked we were promised a sprint where all we would do is tech debt fixes. Guess what never happened since the top brass kept pushing new feature requests on us. Features kept taking longer and longer to implement and every release we had more and more bugs make it into production.

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

    Well, yeah - that never happens. You do tech debt cleanup "as you go". Slip in a few tickets to cleanup specific things and have a policy to update code that is touched when adding features / fixing bugs.

    It needs to be a continual cleaning process. That's why it's called debt - the longer you let it go un-paid the harder it is to do.

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

    I suggested at my current job that we adopt a policy of fixing things as we go. Boss wasn't interested. He said his boss said "he doesn't want people gold plating things".

    Okay. I guess we'll keep this tower of bash scripts that breaks once a month.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 11 points 7 months ago (13 children)

    Why do engineers do this?

    Simply fix the relevant technical debt as part of implementing a feature or fixing a bug. That way you can chip away at it over time.

    Waiting for the big removal of technical debt will never come. It’s an ongoing process.

    Leave the code base better than you found it – always.

    due date next Thursday

    The answer is to say “We will try our best, but this is very ambitious.” Then you let the deadline pass, usually it’s artificial in the first place. When the deadline passes say: “As we feared this took longer than we hoped for.”

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

    The answer is to say “We will try our best, but this is very ambitious.”

    If there’s some urgent feature request coming from sales then that means the Thursday deadline is in the contract and it’s already signed.

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

    So what? If you weren’t consulted when the deadline was set, it’s not your problem. Have some balls and rip your bosses a new one when they pull bullshit like this. “That deadline was unattainable when it was set. Had our team been consulted, we could’ve worked on a solution. But since sales went over our heads, this is their mess to clean up.”

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

    To quote my manager from today: “I don’t want us to spin our wheels and turn this into a month long effort”

    The request is to effectively rearchitect a foundational part of the system. It’s a large lift project that should take weeks.

    Of course I pushed back, I have good rapport with him and I’m not worried about getting fired over this. Not everyone has that.

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

    “This isn’t a bazaar. We don’t haggle over deadlines. We professionally estimate them.”

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

    As the tech lead at my company, I treat all deadlines as fake until proven otherwise.

    Also, when they start pressing me for dates that things can be done, I start multiplying by 4…

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 7 months ago* (last edited 7 months ago)

    Why would you ask permission to do something necessary? Just do it any time you have a ticket in the area.

    One place I worked at had a rule forbidding pure refactors. One, it’s no other department’s (or manager’s) business that you massaged something to be more useful. Two, what is QA supposed to do with a change that has no new features or bug fixes? Three, are you going to put “refactor” in your release notes? Four, why are you refactoring things out of the scope of a feature or bugfix?

  • permalink
  • fedilink
  • source
  • parent