6 ms·

Maybe it's just me but in my career (15 years at this point as a professional software engineer) by FAR the biggest problem is teams not doing enough refactorin

Maybe it's just me but in my career (15 years at this point as a professional software engineer) by FAR the biggest problem is teams not doing enough refactoring. When new features come along that violate basic assumptions of the initial codebase, instead of refactoring out those initial assumptions you hack around them. It's almost always faster to do that then do a proper refactor for a particular feature but over time the codebase devolves into a tangle of spaghetti and incomprehensible chains of if/then/else where variable names have no semantic connection to how they are being used anymore. Sure, you can have the opposite problem where you refactor too eagerly and waste time but all the incentives in a corporate setting work against erring on the side of too much refactoring.

revel 6y ago
Similar experience and totally agree. How often do people go out of their way to improve a severely limiting code base? Not enough.
- LargeWu 6y ago
  Often it's because they are being pressured by leadership not to. Leadership's bonuses and promotions are dependent on developers delivering value NOW.
  - hhas01 6y ago
    Some of that is on developers, famous for overpromising and under-delivering and generally not managing expectations. There is a real skill to effectively explaining a job’s requirements to non-developers, and it’s something I think a lot of us suck hard at. Plenty of it is also on managers who simply aren’t competent to manage, of which there is a tragic abundance. If that really bothers you, move up to management and start doing the job better or go find a new job. Otherwise, not your circus, not your monkeys.† Just make sure to keep your papertrail. -- † Whereas the liabilities for screwing with production code outside your scope of work def should be. Though again, that assumes a management that actually understands what’s going on in its own shop, and isn’t just running around with its hair on fire 24/7.
  - sukilot 6y ago
    Doesn't leadership hold a lot of stock?
nthj 6y ago
Most productive refactoring carries forward from a more effectively designed data model. There can be value in pushing code around but often a lot of that can be subjective, which this thread has discussed. Even big corporations are open to refactoring when you put it in the context of data integrity and consistency (foreign keys), because data inconsistency causes tickets which cause churn which is a number the CEO reports to the board.
- thinkharderdev 6y ago
  Mostly agree but I think the distinction is not always clear between data model changes and changes to application-tier logic. In most cases you can do a particular refactor either way and you have to figure out what is the best way to achieve it. Just pushing code around is usually not tremendously valuable but it's also not particularly costly.
Consultant32452 6y ago
Don't forget halfway refactoring. The worst case I've ever had was a project with 3 completely different and incompatible ways of accomplishing everything. Different packaging schemes, different DAO designs, different UI framework/libraries. The worst!
- thinkharderdev 6y ago
  I think we can all agree that the dev who starts a big refactor and then drops it when it's half-done is a terrible human being
  - bradstewart 6y ago
    I don't agree. Big refactors are _hard_. They usually require levels of sustained focus at multiple layers of abstraction, and its really easy to get exhausted/burnt out or be forced to switch gears in the middle. People learn by doing. And after a few such messes, the dev will learn how to do smaller refactors.
  - droobles 6y ago
    That's me. I want to finish my refactor but business requirements have me pumping out new epics. I chip away at it in my down time but it's no longer prioritized. I find in this line of work, you will always seek to find ways to balance business/market needs vs. being a paragon of programming.
  - mcv 6y ago
    There's not always time to finish it properly, but there's often a good stopping point halfway. When there's a lot that needs refactoring, I start with one specific thing, and leave the rest for now, so the piece I've bitten off is still small enough that it can be wrapped up in a reasonable amount of time. And the rest will have to wait. In my current project, there are piece of code that I've wanted to remove for months now. I was working on refactoring it out completely, but there's one place that still uses it, and that wasn't so easy to fix as all the other places where it had become unnecessary. It still needs to be done, but there hasn't been any time. Or urgency, really. But it's still there, taking up space in my head.
_8ljf 6y ago
Yep, but there you are refactoring as a necessary prerequisite to achieving a clearly-defined end goal. That’s part of the development roadmap and should be planned and budgeted accordingly. When building a house, a professional builder knows to dig out and pour a solid foundation, so that by the time they get to tiling the roof the walls beneath it aren’t already sinking and tearing apart. That’s very different to just dicking with the company codebase for one’s personal amusement. That’s the bloke with the dozen rusted automobile shells sitting on bricks in his front yard, while he’s in his shed “busy working” on number thirteen. He’s not productive, he’s just playing with himself. And making the whole place look like trash while he’s at it.
- thinkharderdev 6y ago
  Right, of course dicking around with the codebase for personal amusement is bad and a poor use of time. But I think refactoring doesn't necessarily have to be achieving a clearly defined end goal to be useful and appropriate. Primary because product development itself doesn't have a clearly defined end goal. It's an iterative process where the end goal can change as you discover new information. To follow on your example, if I'm building a two story house and pour a foundation to support that but then the foreman comes along and says "actually we need to build a ten story office building on the same footprint" then you absolutely should start over and pour a new foundation. If you have a well-defined spec to begin with and it doesn't change and you STILL need to do a bunch of refactoring along the way then you probably did something wrong. But in my experience that is almost never the case. Refactoring happens because the requirements change and assumptions you made are no longer valid.
sigy 6y ago
I find the article quite presumptive in the sense that it presumes everyone has the same definition for "gold plated", etc. That, coupled with the With the remedy of "give the guy something else to do" makes me think that the writer is on the opposite of the spectrum which could be characterized as "throw stuff at the wall and see what sticks." I know this seems pejorative on some level, but I'm trying to paint a contrast here between sensibilities. I think it is worth considering that one person's urgent and long-needed reduction in technical debt is another person's over-engineered. It often comes down to whether the person passing judgement has the awareness of how everything fits together and thus can benefit from a structural tune-up. It could also depend on how many systems and code bases they have had to maintain. I mean, on balance, we have a really bad track record as an industry of building unmaintainable code bases. Most developers are working on the things they find enjoyable with less regard for making it work well for other developers. I think that the author's remedy of splitting these responsibilities out into separate roles is an indicator of the overall problem. It shouldn't have to be framed in that way to make it palatable to the average developer. As a developer, you should always want to make the code you work on work well for others, and that includes refactoring on occasion. If you find yourself in a posture where you are always "innovating the new fun stuff" while others are seemingly dragging you down with making it actually manageable, it's time to slow down enough to realize what this means to your team. By not taking care of your own code so that your other developers find it manageable, you've turned them into your cleanup crew. You need to thank them for being "That coworker" who you find "gold plater, or unproductive, or slow", and perhaps stop building prototypes and calling them done. Just some food for thought.
xupybd 6y ago
This is what I've seen too. Higher pressure to get features out. Then the code gets worse and worse over time. Development gets slower and pressure gets more intense. Then customer gets pissed off and fault lands on the Devs.

revel 6y ago

Similar experience and totally agree. How often do people go out of their way to improve a severely limiting code base? Not enough.

LargeWu 6y ago
Often it's because they are being pressured by leadership not to. Leadership's bonuses and promotions are dependent on developers delivering value NOW.
- hhas01 6y ago
  Some of that is on developers, famous for overpromising and under-delivering and generally not managing expectations. There is a real skill to effectively explaining a job’s requirements to non-developers, and it’s something I think a lot of us suck hard at. Plenty of it is also on managers who simply aren’t competent to manage, of which there is a tragic abundance. If that really bothers you, move up to management and start doing the job better or go find a new job. Otherwise, not your circus, not your monkeys.† Just make sure to keep your papertrail. -- † Whereas the liabilities for screwing with production code outside your scope of work def should be. Though again, that assumes a management that actually understands what’s going on in its own shop, and isn’t just running around with its hair on fire 24/7.
- sukilot 6y ago
  Doesn't leadership hold a lot of stock?

nthj 6y ago

Most productive refactoring carries forward from a more effectively designed data model. There can be value in pushing code around but often a lot of that can be subjective, which this thread has discussed. Even big corporations are open to refactoring when you put it in the context of data integrity and consistency (foreign keys), because data inconsistency causes tickets which cause churn which is a number the CEO reports to the board.

thinkharderdev 6y ago
Mostly agree but I think the distinction is not always clear between data model changes and changes to application-tier logic. In most cases you can do a particular refactor either way and you have to figure out what is the best way to achieve it. Just pushing code around is usually not tremendously valuable but it's also not particularly costly.

Consultant32452 6y ago

Don't forget halfway refactoring. The worst case I've ever had was a project with 3 completely different and incompatible ways of accomplishing everything. Different packaging schemes, different DAO designs, different UI framework/libraries. The worst!

thinkharderdev 6y ago
I think we can all agree that the dev who starts a big refactor and then drops it when it's half-done is a terrible human being
- bradstewart 6y ago
  I don't agree. Big refactors are _hard_. They usually require levels of sustained focus at multiple layers of abstraction, and its really easy to get exhausted/burnt out or be forced to switch gears in the middle. People learn by doing. And after a few such messes, the dev will learn how to do smaller refactors.
- droobles 6y ago
  That's me. I want to finish my refactor but business requirements have me pumping out new epics. I chip away at it in my down time but it's no longer prioritized. I find in this line of work, you will always seek to find ways to balance business/market needs vs. being a paragon of programming.
- mcv 6y ago
  There's not always time to finish it properly, but there's often a good stopping point halfway. When there's a lot that needs refactoring, I start with one specific thing, and leave the rest for now, so the piece I've bitten off is still small enough that it can be wrapped up in a reasonable amount of time. And the rest will have to wait. In my current project, there are piece of code that I've wanted to remove for months now. I was working on refactoring it out completely, but there's one place that still uses it, and that wasn't so easy to fix as all the other places where it had become unnecessary. It still needs to be done, but there hasn't been any time. Or urgency, really. But it's still there, taking up space in my head.

_8ljf 6y ago

Yep, but there you are refactoring as a necessary prerequisite to achieving a clearly-defined end goal. That’s part of the development roadmap and should be planned and budgeted accordingly. When building a house, a professional builder knows to dig out and pour a solid foundation, so that by the time they get to tiling the roof the walls beneath it aren’t already sinking and tearing apart. That’s very different to just dicking with the company codebase for one’s personal amusement. That’s the bloke with the dozen rusted automobile shells sitting on bricks in his front yard, while he’s in his shed “busy working” on number thirteen. He’s not productive, he’s just playing with himself. And making the whole place look like trash while he’s at it.

thinkharderdev 6y ago
Right, of course dicking around with the codebase for personal amusement is bad and a poor use of time. But I think refactoring doesn't necessarily have to be achieving a clearly defined end goal to be useful and appropriate. Primary because product development itself doesn't have a clearly defined end goal. It's an iterative process where the end goal can change as you discover new information. To follow on your example, if I'm building a two story house and pour a foundation to support that but then the foreman comes along and says "actually we need to build a ten story office building on the same footprint" then you absolutely should start over and pour a new foundation. If you have a well-defined spec to begin with and it doesn't change and you STILL need to do a bunch of refactoring along the way then you probably did something wrong. But in my experience that is almost never the case. Refactoring happens because the requirements change and assumptions you made are no longer valid.

sigy 6y ago

I find the article quite presumptive in the sense that it presumes everyone has the same definition for "gold plated", etc. That, coupled with the With the remedy of "give the guy something else to do" makes me think that the writer is on the opposite of the spectrum which could be characterized as "throw stuff at the wall and see what sticks." I know this seems pejorative on some level, but I'm trying to paint a contrast here between sensibilities. I think it is worth considering that one person's urgent and long-needed reduction in technical debt is another person's over-engineered. It often comes down to whether the person passing judgement has the awareness of how everything fits together and thus can benefit from a structural tune-up. It could also depend on how many systems and code bases they have had to maintain. I mean, on balance, we have a really bad track record as an industry of building unmaintainable code bases. Most developers are working on the things they find enjoyable with less regard for making it work well for other developers. I think that the author's remedy of splitting these responsibilities out into separate roles is an indicator of the overall problem. It shouldn't have to be framed in that way to make it palatable to the average developer. As a developer, you should always want to make the code you work on work well for others, and that includes refactoring on occasion. If you find yourself in a posture where you are always "innovating the new fun stuff" while others are seemingly dragging you down with making it actually manageable, it's time to slow down enough to realize what this means to your team. By not taking care of your own code so that your other developers find it manageable, you've turned them into your cleanup crew. You need to thank them for being "That coworker" who you find "gold plater, or unproductive, or slow", and perhaps stop building prototypes and calling them done. Just some food for thought.

xupybd 6y ago

This is what I've seen too. Higher pressure to get features out. Then the code gets worse and worse over time. Development gets slower and pressure gets more intense. Then customer gets pissed off and fault lands on the Devs.