10 ms·

Nice article! I'd like to a software methodology more supportive of what I'd call "Continuous refactoring" or a more "kaizen"-like mindset. "Agile" isn't always

by mhomde 9y ago

Nice article! I'd like to a software methodology more supportive of what I'd call "Continuous refactoring" or a more "kaizen"-like mindset. "Agile" isn't always as agile as I'd like, but becomes rigid in peoples interpretation of the rules. It's a constant fight to keep down the number of lines of code and complexity, in large projects. Once a code-base passes beyond a certain point it becomes difficult to see redundancies and patterns. Bloated code breeds bloated code. If you on the other hand keep trimming and keep refactoring deep and wide as the code and requirements change you can often keep things manageable and understandable. "bad code" get's easier to spot, it's a little bit like the broken windows theory. Scrum IMO and a lot of the agile methodologies, at least in their implementation, in my experience, tends to treat projects like brick-building and lacks a way to support and enforce constant re-architecturing and removal of code smells. If code quality and refactoring is not supported by the actual methodology it can become an bureaucratic problem where product owners doesn't see the value and doesn't prioritize it (even though it leads to quicker development time and less bugs in the long run) Unit testing is supposed to make refactoring easier, but can become an impediment to refactoring as well, as the cost of rewriting tests can be seen as too high. We're currently experimenting with having one hour meeting each week where you can discuss things like that, and then dedicating some time to refactor, we'll see how it works out :)

zwischenzug 9y ago
That sounds like the 'healthy' team I talk about in the article. The problem with the 'continuous refactoring' (in my experience) is that the people that hold the purse strings cannot grasp the benefit, so cut this early.
- crdoconnor 9y ago
  Sometimes they're right. I'd prefer a methodology where the people who hold the purse strings have to explicitly declare their current desired emphasis on dev velocity / quality. At the moment every single methodology requires devs make that decision even though it's really a bizdev decision.
  - mhomde 9y ago
    I don't know, when it comes to code quality and things like that I'd rather prefer a methodology that insulates it against bureaucracy rather than involves it. Keep the Dilbertian forces at bay. Product owners should prioritize feature set, requirements and sometimes bugs, but the less they have to do with the intrinsics of reaching them the better.
    - crdoconnor 9y ago
      I think their involvement should be strictly limited to telling developers what % of their time they're to spend on refactoring/tooling. This actually avoids dilbertian forces - the PM can't weasel out of responsibility for pressuring you to deliver shit quickly. That % would stick out like a sore thumb if it was permanently under, say, 15%.
      - mhomde 9y ago
        Unfortunately IMO that kind of thinking seldom works. It's very managerial to assign specific time and percentages to things but in practice I've never known development to be managed that way. Also you underestimate their weaselness :) Refactoring needs to be an integral and constant part of the development, in the long run that will decrease time needed for refactoring, and time required to fix bugs. But that time is variable, and might come in large chunks depending on how much technical debt you've accumulated
        crdoconnor 9y ago
        Precision isn't the issue. Story pointing isn't supposed to be 100% accurate either. It's supposed to shine a light on an otherwise opaque process. It works at that. This is the same. I could quite easily spend all of my time refactoring and none on features and vice versa. There is no "right" amount as you seem to think, just a whole bunch of trade offs. I think you underestimate the power of making something measurable and exposing it to upper management. That often changes behaviour in a quite radical way, especially among weasels. And, you've never known development to be managed in this way because it's a new idea.
- mhomde 9y ago
  Yeah totally, but if was intrinsic to a trendy methodology you might be able to shield it better in the same way you do stuff in the name of being ISO-whatever compliant :)
  - TheCoelacanth 9y ago
    It is intrinsic to XP. One of the rules is "Refactor Mercilessly"[1]. [1] http://www.extremeprogramming.org/rules/refactor.html http://www.extremeprogramming.org/rules/refactor.html
- arethuza 9y ago
  In my experience, the easiest way to get 'continuous refactoring' done is to build it into all estimates without telling whoever controls the 'purse strings' ....
  - mhomde 9y ago
    yeah, that's what's often is being done. But it prevents the methodology to have some useful best practices built into it, and a methodology could be a force in improving code quality and keeping it intact over time, which is from all the projects I've seen severely needed
    - nradov 9y ago
      Scaled Agile Framework (SAFe) explicitly has that useful best practice built into it. http://www.scaledagileframework.com/refactoring/ http://www.scaledagileframework.com/refactoring/
- user5994461 9y ago
  The problem with refactoring is that developers think it's a task of it's own. They want time to do it, they want special estimate, they want it to become a thing of its own. Refactoring is low level work that is part of every task, it should not even be mentioned. When you ask your mechanic to change wheels, you don't expect him to explain that he will have to take off the previous wheel and change the screws, that will be an item on the bill consuming half of the budget.
  - mhomde 9y ago
    Some developers think that, and unfortunately a lot of methodology enforces that thinking. Cleaning up code as you go should be a habit I agree. It's slightly trickier when code reaches a "boiling frog" point and you need to take a look at the bigger picture and perhaps re-architecture. It often easy to keep chugging away at the tree's and not seeing the forest. The downside with the scope of those kind of structural refactoring is that they touch a lot of code, so they're perceived as "risky". Also developers get attached to the architecture they have learnt and know, and don't want to re-learn, even if the simplified code would be easier to learn for someone new
  - aninhumer 9y ago
    Not all refactoring fit neatly alongside existing work. Sometimes you get a small change request that suggests a broader refactoring. You're pretty sure it will be valuable in future, but it would be a lot more work and isn't that useful in the short term. So if you try and do that refactoring upfront, you get pushback for wasting time on a small change. And then again on the next relevant change. Developers often want to schedule these kinds of refactorings, because otherwise they get pushback on every chance they might otherwise have to fix these problems.
    - user5994461 9y ago
      Not all refactoring fit neatly alongside existing work... because every refactoring fits nearty alongside the new work. In your example, you don't refactor for fun, you refactor to integrate new things. Integrate the refactoring as part of the new work. Guess what. The mechanic too has to deal with the old wheels, and don't get him started on the old screws that broke and the assembly that had to be cleaned just to work in decent conditions.
nradov 9y ago
Scaled Agile Framework (SAFe) places a heavy emphasis on continuous refactoring. http://www.scaledagileframework.com/refactoring/ http://www.scaledagileframework.com/refactoring/
- virgilp 9y ago
  That's a lousy abbreviation - SAFr ("safer") would've been so much better.
  - exelius 9y ago
    Technically it's SAF-e -- Scaled Agile Framework for (e)nterprise.
    - nradov 9y ago
      No the official abbreviation is "SAFe", not "SAF-e".
      - exelius 9y ago
        I realize that, I was separating for effect. :)
s73ver_ 9y ago
""Agile" isn't always as agile as I'd like, but becomes rigid in peoples interpretation of the rules." I think a lot of this is because, if you don't enforce the rules rigidly, they tend to get cast by the wayside, especially by management.
specialist 9y ago
The Agile methodology is to argue about the Agile methodology. PMI style critical path, planning backwards from the release, is the only approach I’ve ever seen that was clear, concrete, actionable, high functioning.

by mhomde 9y ago

zwischenzug 9y ago

That sounds like the 'healthy' team I talk about in the article. The problem with the 'continuous refactoring' (in my experience) is that the people that hold the purse strings cannot grasp the benefit, so cut this early.

crdoconnor 9y ago
Sometimes they're right. I'd prefer a methodology where the people who hold the purse strings have to explicitly declare their current desired emphasis on dev velocity / quality. At the moment every single methodology requires devs make that decision even though it's really a bizdev decision.
- mhomde 9y ago
  I don't know, when it comes to code quality and things like that I'd rather prefer a methodology that insulates it against bureaucracy rather than involves it. Keep the Dilbertian forces at bay. Product owners should prioritize feature set, requirements and sometimes bugs, but the less they have to do with the intrinsics of reaching them the better.
  - crdoconnor 9y ago
    I think their involvement should be strictly limited to telling developers what % of their time they're to spend on refactoring/tooling. This actually avoids dilbertian forces - the PM can't weasel out of responsibility for pressuring you to deliver shit quickly. That % would stick out like a sore thumb if it was permanently under, say, 15%.
    - mhomde 9y ago
      Unfortunately IMO that kind of thinking seldom works. It's very managerial to assign specific time and percentages to things but in practice I've never known development to be managed that way. Also you underestimate their weaselness :) Refactoring needs to be an integral and constant part of the development, in the long run that will decrease time needed for refactoring, and time required to fix bugs. But that time is variable, and might come in large chunks depending on how much technical debt you've accumulated
      - crdoconnor 9y ago
        Precision isn't the issue. Story pointing isn't supposed to be 100% accurate either. It's supposed to shine a light on an otherwise opaque process. It works at that. This is the same. I could quite easily spend all of my time refactoring and none on features and vice versa. There is no "right" amount as you seem to think, just a whole bunch of trade offs. I think you underestimate the power of making something measurable and exposing it to upper management. That often changes behaviour in a quite radical way, especially among weasels. And, you've never known development to be managed in this way because it's a new idea.
mhomde 9y ago
Yeah totally, but if was intrinsic to a trendy methodology you might be able to shield it better in the same way you do stuff in the name of being ISO-whatever compliant :)
- TheCoelacanth 9y ago
  It is intrinsic to XP. One of the rules is "Refactor Mercilessly"[1]. [1] http://www.extremeprogramming.org/rules/refactor.html http://www.extremeprogramming.org/rules/refactor.html
arethuza 9y ago
In my experience, the easiest way to get 'continuous refactoring' done is to build it into all estimates without telling whoever controls the 'purse strings' ....
- mhomde 9y ago
  yeah, that's what's often is being done. But it prevents the methodology to have some useful best practices built into it, and a methodology could be a force in improving code quality and keeping it intact over time, which is from all the projects I've seen severely needed
  - nradov 9y ago
    Scaled Agile Framework (SAFe) explicitly has that useful best practice built into it. http://www.scaledagileframework.com/refactoring/ http://www.scaledagileframework.com/refactoring/
user5994461 9y ago
The problem with refactoring is that developers think it's a task of it's own. They want time to do it, they want special estimate, they want it to become a thing of its own. Refactoring is low level work that is part of every task, it should not even be mentioned. When you ask your mechanic to change wheels, you don't expect him to explain that he will have to take off the previous wheel and change the screws, that will be an item on the bill consuming half of the budget.
- mhomde 9y ago
  Some developers think that, and unfortunately a lot of methodology enforces that thinking. Cleaning up code as you go should be a habit I agree. It's slightly trickier when code reaches a "boiling frog" point and you need to take a look at the bigger picture and perhaps re-architecture. It often easy to keep chugging away at the tree's and not seeing the forest. The downside with the scope of those kind of structural refactoring is that they touch a lot of code, so they're perceived as "risky". Also developers get attached to the architecture they have learnt and know, and don't want to re-learn, even if the simplified code would be easier to learn for someone new
- aninhumer 9y ago
  Not all refactoring fit neatly alongside existing work. Sometimes you get a small change request that suggests a broader refactoring. You're pretty sure it will be valuable in future, but it would be a lot more work and isn't that useful in the short term. So if you try and do that refactoring upfront, you get pushback for wasting time on a small change. And then again on the next relevant change. Developers often want to schedule these kinds of refactorings, because otherwise they get pushback on every chance they might otherwise have to fix these problems.
  - user5994461 9y ago
    Not all refactoring fit neatly alongside existing work... because every refactoring fits nearty alongside the new work. In your example, you don't refactor for fun, you refactor to integrate new things. Integrate the refactoring as part of the new work. Guess what. The mechanic too has to deal with the old wheels, and don't get him started on the old screws that broke and the assembly that had to be cleaned just to work in decent conditions.

nradov 9y ago

Scaled Agile Framework (SAFe) places a heavy emphasis on continuous refactoring. http://www.scaledagileframework.com/refactoring/ http://www.scaledagileframework.com/refactoring/

virgilp 9y ago
That's a lousy abbreviation - SAFr ("safer") would've been so much better.
- exelius 9y ago
  Technically it's SAF-e -- Scaled Agile Framework for (e)nterprise.
  - nradov 9y ago
    No the official abbreviation is "SAFe", not "SAF-e".
    - exelius 9y ago
      I realize that, I was separating for effect. :)

s73ver_ 9y ago

""Agile" isn't always as agile as I'd like, but becomes rigid in peoples interpretation of the rules." I think a lot of this is because, if you don't enforce the rules rigidly, they tend to get cast by the wayside, especially by management.

specialist 9y ago

The Agile methodology is to argue about the Agile methodology. PMI style critical path, planning backwards from the release, is the only approach I’ve ever seen that was clear, concrete, actionable, high functioning.