6 ms·

In my experience, Freds are often a holdover from an earlier time in the companies' life when autonomy was not only desirable but required. Some years pass, a f

by WJW 6y ago

In my experience, Freds are often a holdover from an earlier time in the companies' life when autonomy was not only desirable but required. Some years pass, a few managers get hired between the CTO and Fred and sooner or later the manager needs Fred to fall in line because he makes the manager look bad. Eventually the "make a ticket for everything" scrum crowd wins out and it's now Fred's fault for refactoring without a ticket. Fred long ago learned that refactoring tickets always mysteriously sink to the bottom of the backlog, so he doesn't make them anymore. TBH, the Freds I encountered are not really in any danger of getting fired. Because they were the only ones touching all parts of the codebase with their refactorings, they were pretty much walking bus factors.

thinkharderdev 6y ago
"Fred long ago learned that refactoring tickets always mysteriously sink to the bottom of the backlog, so he doesn't make them anymore." Exactly this. Maybe Fred understands that if he creates a ticket to do a required refactor then it will never get prioritized and when things blow up in production 2 months from now it's his phone that's going to ring in the middle of the night.
- schwartzworld 6y ago
  Fred knows the codebase so well he has a list of functionality he wants to rewrite. He patiently waits until a ticket comes up in the backlog that touches that code.
mcv 6y ago
I make tickets for my refactorings. Solving tech debt is also important. You're spot on, though. I'm currently in a position where I refactor a lot. This is in a team that started with just me cobbling together a prototype, later with two other freelancers. We'd regularly completely reorganise our entire stack, because we were still figuring stuff out. Now it's a team with 7 developers, an actual PO, a separate scrum master and a designer, and I still love to refactor stuff while everybody else is building features. Another freelancer that's still left is our infra guru and he keeps tinkering with that instead of building features, but it's definitely helping the team.
- bradlys 6y ago
  > I make tickets for my refactorings. Solving tech debt is also important. You're right - it's important. But, guess what, most business people have no idea what refactoring means and no amount of explaining seems to get that through. They think it means developers get the equivalent of a paid holiday because of some preconceived notion they had at some other company they worked at.
  - mcv 6y ago
    Then explain to them why it's important. That we don't want the code to turn into an unmaintainable mess. That maintainance costs dwarf initial development costs. That this is not some sort of hobby project, but a professional, production-quality project where you can't afford to let code quality drop.
    - bradlys 6y ago
      I've tried many times. It usually comes down to this: "I don't get it. We've managed for so long to do things quickly - why is it now that we can't go fast?" Unless they wrote code in the last few years - I don't see people ever relating. It's just some abstract problem to them and you never get enough time to thoroughly explain how it all works. Unfortunately, we're not like a factory. You can't make the retooling argument in the same way and see blatantly obvious results. It's more nebulous. If someone out there figures it out - I'm sure we'd never have these discussions. They'd say, "Oh, why don't you just use the bradlys argument? He wrote it up on HN some years back and this refactoring discussion has been solved ever since."
      - mcv 6y ago
        > "I don't get it. We've managed for so long to do things quickly - why is it now that we can't go fast?" "You can go fast when you're rapidly prototyping something that doesn't have to go to production, doesn't have to support thousands of users, is allowed to fall over at any time, and doesn't need to be maintained. You can also go fast when you're working on a well-designed system that is designed to support what you're trying to do. But the moment you start making it do something it wasn't originally designed to do, you slow down, and you risk turning the code into a mess that will slow you down even further in the future. If you want to go fast, let us refactor it now, so it will support the things we want to use it for." And if they don't get that, maybe they shouldn't be in a position to make decisions about this sort of thing. Though I guess they won't respond well to you telling them that.

by WJW 6y ago

thinkharderdev 6y ago

"Fred long ago learned that refactoring tickets always mysteriously sink to the bottom of the backlog, so he doesn't make them anymore." Exactly this. Maybe Fred understands that if he creates a ticket to do a required refactor then it will never get prioritized and when things blow up in production 2 months from now it's his phone that's going to ring in the middle of the night.

schwartzworld 6y ago
Fred knows the codebase so well he has a list of functionality he wants to rewrite. He patiently waits until a ticket comes up in the backlog that touches that code.

mcv 6y ago

I make tickets for my refactorings. Solving tech debt is also important. You're spot on, though. I'm currently in a position where I refactor a lot. This is in a team that started with just me cobbling together a prototype, later with two other freelancers. We'd regularly completely reorganise our entire stack, because we were still figuring stuff out. Now it's a team with 7 developers, an actual PO, a separate scrum master and a designer, and I still love to refactor stuff while everybody else is building features. Another freelancer that's still left is our infra guru and he keeps tinkering with that instead of building features, but it's definitely helping the team.

bradlys 6y ago
> I make tickets for my refactorings. Solving tech debt is also important. You're right - it's important. But, guess what, most business people have no idea what refactoring means and no amount of explaining seems to get that through. They think it means developers get the equivalent of a paid holiday because of some preconceived notion they had at some other company they worked at.
- mcv 6y ago
  Then explain to them why it's important. That we don't want the code to turn into an unmaintainable mess. That maintainance costs dwarf initial development costs. That this is not some sort of hobby project, but a professional, production-quality project where you can't afford to let code quality drop.
  - bradlys 6y ago
    I've tried many times. It usually comes down to this: "I don't get it. We've managed for so long to do things quickly - why is it now that we can't go fast?" Unless they wrote code in the last few years - I don't see people ever relating. It's just some abstract problem to them and you never get enough time to thoroughly explain how it all works. Unfortunately, we're not like a factory. You can't make the retooling argument in the same way and see blatantly obvious results. It's more nebulous. If someone out there figures it out - I'm sure we'd never have these discussions. They'd say, "Oh, why don't you just use the bradlys argument? He wrote it up on HN some years back and this refactoring discussion has been solved ever since."
    - mcv 6y ago
      > "I don't get it. We've managed for so long to do things quickly - why is it now that we can't go fast?" "You can go fast when you're rapidly prototyping something that doesn't have to go to production, doesn't have to support thousands of users, is allowed to fall over at any time, and doesn't need to be maintained. You can also go fast when you're working on a well-designed system that is designed to support what you're trying to do. But the moment you start making it do something it wasn't originally designed to do, you slow down, and you risk turning the code into a mess that will slow you down even further in the future. If you want to go fast, let us refactor it now, so it will support the things we want to use it for." And if they don't get that, maybe they shouldn't be in a position to make decisions about this sort of thing. Though I guess they won't respond well to you telling them that.