6 ms·

Again, I'm not defending every single workplace here. Obviously some developers aren't treated well, and in those cases, they should find another job. I was com

by edanm 5y ago

Again, I'm not defending every single workplace here. Obviously some developers aren't treated well, and in those cases, they should find another job. I was commenting on the fairly blanket statement made. But the way the conversation should go isn't the developer deciding when refactoring should happen. It's the developer giving an analysis of the cost and benefit of a refactoring (it will take X time, but will save Y work in the future). And the manager factoring that into all the other circumstances, and deciding whether it's worth the current cost.

mibollma 5y ago
> It's the developer giving an analysis of the cost and benefit of a refactoring (it will take X time, but will save Y work in the future). And the manager factoring that into all the other circumstances, and deciding whether it's worth the current cost. I don't think either devlopers or managers can estimate future savings in most cases, but I still think it's necessary to refactor just to not drown in complexity and slow down overall development speed. My approach is to reserve about 20% for refactoring and technical improvements and let the team decide internally what to use it on.
- cudgy 5y ago
  Why 20%? Just curious how you arrived at that percentage.
  - mibollma 5y ago
    Thats why I said "about" 20%, so it differs based on project and situation. Enough to get useful stuff done, small enough to keep most capacity for feature development. Also depends on the amount of technical tickets deemed relevant by the team
  - pirate787 5y ago
    Pareto optimal
    - cudgy 5y ago
      That assumes there are equal weights to the factors.
pdimitar 5y ago
> It's the developer giving an analysis of the cost and benefit of a refactoring (it will take X time, but will save Y work in the future). And the manager factoring that into all the other circumstances, and deciding whether it's worth the current cost. This has been the ideal theory for decades and I really wish people finally stopped to think for two minutes, look around, read some history and finally understand that it's not working. Is it really so hard to accept this reality? I am periodically mind-boggled by the amazingly resilient illusion that you can plan things as tidily. It never happened, not once, in my 20 years of career. Estimating these costs upfront is more or less impossible. It's usually a can of worms that opens other brand new and exciting sub-tasks, the same kind that gives managers nightmares. IMO you might have projected a little bit and arguing against some imaginary "us the programmers are better than everyone else". Meh. Only kiddos think and say things like that. By and large, almost all experienced programmers I've ever met are quite moderate and humble. Problem is, they are too moderate and humble which leads to predatory businessmen micro-managing them to oblivion. I've personally witnessed high-profile programmers firmly saying "No!", putting their foot down and making a thing their way with more time budget. Their project and code was used, almost untouched, for 10+ years afterwards -- it was that good. Many of us are expert artisans. You don't go to a professional blacksmith giving him wisdom how can he accelerate a certain process.
- bob1029 5y ago
  I think the key point for me is that once you control for all common human flaws, the developer is still far better suited to make an executive decision regarding a technology concern than anyone else on the team. I recently made the mistake of deferring to the anxieties and fears of non-developers for so long that I almost forgot how we got to where we are today or what my true capabilities are. You know exactly what those assholes are thinking when you say the word "refactor" or "iterate". It starts to become a psychological horror experience if you let it get out of control for too long. Now don't get me wrong. At the end of the day I love and care for our customer too. I just don't let their minute-by-minute feature request stream live rent free in my head the same way the rest of the team does.
  - 5y ago
Dave3of5 5y ago
For non-tech people the code should be a black box they shouldn't know the internal details. In terms of refactoring there is no way to give a Cost Benefit analysis as that's too subjective. This should be a maintenance cost that's factored into the project at a high level. So you would say there a X days per year (normally about 20%) of the working days of the year spent on maintenance. Company I'm at has this and if you're doing this type of work then you have timecodes to book your time against. That includes refactoring, re-architecture, tech debt, updating deps ...etc. PM's can't override this for their own project i.e. they have to allow for 20% off project activities in there Project Plan. Devs shouldn't spend more that 20% of their time doing these activities over the FY. Example here would be in the UK we have something called a MOT which you have to legally get it's like a minimal maintenance you have to get on your car. Most people spend a little more though than the minimum.
- rand49an 5y ago
  An MOT is a bad example because they don't do any maintenance at all. An MOT is essentially a safety certificate to make sure you aren't driving around in a car that's due to fall apart and injure yourself and others. How you attain that certificate (by ongoing maintenance) doesn't matter.
  - Dave3of5 5y ago
    No it's not. The MOT is a test that you have performed maintenance so the example stands. You can do 0 maintenance and still get your MOT. likewise in software you can do zero maintenance and still have a good well working product that follows best practice. In the case I gave it's hours book on the maintenance project that is the test but you could very well have other measures and I've seen these in many projects. Things like linters, dependency bots, unit tests, e2e tests, code coverage, Cyclomatic complexity ...etc.
- edanm 5y ago
  > For non-tech people the code should be a black box they shouldn't know the internal details. Ideally, yes, though in practice this usually breaks in various ways, especially when problems occur. E.g. the President of a country probably doesn't need to be a firefighter, but if there's suddenly a massive fire, I assume he'd need to be briefed in far more detail to help call shots around the type of response. > In terms of refactoring there is no way to give a Cost Benefit analysis as that's too subjective. I mean, you probably won't get a very correct Cost Benefit analysis, but you have to do something. The rest of your post is you describing that something - if you elect to spend 20% of your time on maintenance, that's effectively giving it a certain amount of weight compared to other things you can be doing with your time. That's certainly one way to work. Personally, I think a more flexible approach is better. E.g. new startup-ish projects should usually spend a lot less time refactoring, for multiple reasons, whereas more established long-term projects should spend much closer to 20%, or maybe more.
Aeolun 5y ago
> It's the developer giving an analysis of the cost and benefit of a refactoring (it will take X time, but will save Y work in the future). I think I just fundamentally disagree that this is the managers job. He tells me what needs doing, and I get that done as soon as possible within a given block of time (mostly sprints, so two weeks). They should be able to trust me to refactor as necessary within that block.
- therealdrag0 5y ago
  Well of course you can. But that sounds like a less powerful position. Being able to refactor a scope that can fit into a sprint without communicating it is (should be) like a non issue. If you’re manager cares, that’s too bad and sad. Personally no where I’ve worked has this been unacceptable or questionable. Hoping that’s the norm, but maybe not. I think the more interesting scenario is large tech debts that take real time, like the change itself is weeks, or months. These need to be justified and planned and coordinated with managers.
flippinburgers 5y ago
I would absolutely love to know what formula could possibly determine time saved in the future.

by edanm 5y ago

mibollma 5y ago

cudgy 5y ago
Why 20%? Just curious how you arrived at that percentage.
- mibollma 5y ago
  Thats why I said "about" 20%, so it differs based on project and situation. Enough to get useful stuff done, small enough to keep most capacity for feature development. Also depends on the amount of technical tickets deemed relevant by the team
- pirate787 5y ago
  Pareto optimal
  - cudgy 5y ago
    That assumes there are equal weights to the factors.

pdimitar 5y ago

> It's the developer giving an analysis of the cost and benefit of a refactoring (it will take X time, but will save Y work in the future). And the manager factoring that into all the other circumstances, and deciding whether it's worth the current cost. This has been the ideal theory for decades and I really wish people finally stopped to think for two minutes, look around, read some history and finally understand that it's not working. Is it really so hard to accept this reality? I am periodically mind-boggled by the amazingly resilient illusion that you can plan things as tidily. It never happened, not once, in my 20 years of career. Estimating these costs upfront is more or less impossible. It's usually a can of worms that opens other brand new and exciting sub-tasks, the same kind that gives managers nightmares. IMO you might have projected a little bit and arguing against some imaginary "us the programmers are better than everyone else". Meh. Only kiddos think and say things like that. By and large, almost all experienced programmers I've ever met are quite moderate and humble. Problem is, they are too moderate and humble which leads to predatory businessmen micro-managing them to oblivion. I've personally witnessed high-profile programmers firmly saying "No!", putting their foot down and making a thing their way with more time budget. Their project and code was used, almost untouched, for 10+ years afterwards -- it was that good. Many of us are expert artisans. You don't go to a professional blacksmith giving him wisdom how can he accelerate a certain process.

bob1029 5y ago
I think the key point for me is that once you control for all common human flaws, the developer is still far better suited to make an executive decision regarding a technology concern than anyone else on the team. I recently made the mistake of deferring to the anxieties and fears of non-developers for so long that I almost forgot how we got to where we are today or what my true capabilities are. You know exactly what those assholes are thinking when you say the word "refactor" or "iterate". It starts to become a psychological horror experience if you let it get out of control for too long. Now don't get me wrong. At the end of the day I love and care for our customer too. I just don't let their minute-by-minute feature request stream live rent free in my head the same way the rest of the team does.
- 5y ago

Dave3of5 5y ago

For non-tech people the code should be a black box they shouldn't know the internal details. In terms of refactoring there is no way to give a Cost Benefit analysis as that's too subjective. This should be a maintenance cost that's factored into the project at a high level. So you would say there a X days per year (normally about 20%) of the working days of the year spent on maintenance. Company I'm at has this and if you're doing this type of work then you have timecodes to book your time against. That includes refactoring, re-architecture, tech debt, updating deps ...etc. PM's can't override this for their own project i.e. they have to allow for 20% off project activities in there Project Plan. Devs shouldn't spend more that 20% of their time doing these activities over the FY. Example here would be in the UK we have something called a MOT which you have to legally get it's like a minimal maintenance you have to get on your car. Most people spend a little more though than the minimum.

rand49an 5y ago
An MOT is a bad example because they don't do any maintenance at all. An MOT is essentially a safety certificate to make sure you aren't driving around in a car that's due to fall apart and injure yourself and others. How you attain that certificate (by ongoing maintenance) doesn't matter.
- Dave3of5 5y ago
  No it's not. The MOT is a test that you have performed maintenance so the example stands. You can do 0 maintenance and still get your MOT. likewise in software you can do zero maintenance and still have a good well working product that follows best practice. In the case I gave it's hours book on the maintenance project that is the test but you could very well have other measures and I've seen these in many projects. Things like linters, dependency bots, unit tests, e2e tests, code coverage, Cyclomatic complexity ...etc.
edanm 5y ago
> For non-tech people the code should be a black box they shouldn't know the internal details. Ideally, yes, though in practice this usually breaks in various ways, especially when problems occur. E.g. the President of a country probably doesn't need to be a firefighter, but if there's suddenly a massive fire, I assume he'd need to be briefed in far more detail to help call shots around the type of response. > In terms of refactoring there is no way to give a Cost Benefit analysis as that's too subjective. I mean, you probably won't get a very correct Cost Benefit analysis, but you have to do something. The rest of your post is you describing that something - if you elect to spend 20% of your time on maintenance, that's effectively giving it a certain amount of weight compared to other things you can be doing with your time. That's certainly one way to work. Personally, I think a more flexible approach is better. E.g. new startup-ish projects should usually spend a lot less time refactoring, for multiple reasons, whereas more established long-term projects should spend much closer to 20%, or maybe more.

Aeolun 5y ago

> It's the developer giving an analysis of the cost and benefit of a refactoring (it will take X time, but will save Y work in the future). I think I just fundamentally disagree that this is the managers job. He tells me what needs doing, and I get that done as soon as possible within a given block of time (mostly sprints, so two weeks). They should be able to trust me to refactor as necessary within that block.

therealdrag0 5y ago
Well of course you can. But that sounds like a less powerful position. Being able to refactor a scope that can fit into a sprint without communicating it is (should be) like a non issue. If you’re manager cares, that’s too bad and sad. Personally no where I’ve worked has this been unacceptable or questionable. Hoping that’s the norm, but maybe not. I think the more interesting scenario is large tech debts that take real time, like the change itself is weeks, or months. These need to be justified and planned and coordinated with managers.

flippinburgers 5y ago

I would absolutely love to know what formula could possibly determine time saved in the future.