3 ms·

The less you know about code, the more local your changes. In fact this is how the architecture of a software system degrades: lots of local changes sort of mak

The less you know about code, the more local your changes. In fact this is how the architecture of a software system degrades: lots of local changes sort of make it "melt". Global invariants become temporally or spatially local invariants, code and data flow which had a single purpose acquire multiple purposes, names become semantically overloaded, and so on.

OliverM 5y ago
Do you know of any external, authoritative studies demonstrating this? I know it's true from long experience of seeing it happen repeatedly, but I'd like to point at something that can justify a 'refactoring sprint' or something like that to try tackling the impact of this pattern. The other justification is that clean refactored codebases are quicker to change, but it's a difficult sell.
- adamkl 5y ago
  Maybe not exactly what you’re looking for, but this is a classic paper on the topic: http://laputan.org/mud/ http://laputan.org/mud/
codeflo 5y ago
Very true. Some things I also noticed: Changes tend to be made higher up in the stack, ultimately the UI, because that has a lower risk of breaking something else. This gets very messy very fast. Bugs in shared code tend to be worked around rather than fixed because other code might depend on those bugs — which quickly becomes a self-fulfilling prophecy. Some functions/methods seem to be natural magnets for these overly local changes, and as a result, can wildly grow in size over time. I once analyzed how a 50-line function had grown to 5000 lines over a few years in a series of individually justifiable changes. All of this is a downwards spiral that’s very hard to stop once it has started. “Refactoring sprints” and other heroic efforts sadly seem to have little impact in such an environment if they don’t also radically address the engineering practices that lead to the situation.
- hobs 5y ago
  The key is the last sentence, its like someone who scheduled a liposuction every year or two to deal with the problem of eating 12 pizzas every day.
cesaref 5y ago
The other side of the coin though is that when you are too close to your code, you can't see some of the refactoring patterns which will simplify it. Fresh eyes bring this to the party. So as ever, a mix of approaches, competencies and knowledge give the best result. And I disagree about this being what goes wrong with architectures. From my experience this is more to do with entropy than anything else. It takes a continual input of effort to 'tidy up' change to keep things looking neat, and this is often ignored or under-estimated until it's too late. The other reason is when the architecture isn't fit for purpose so has to be bent to fit around the problem it's being used to solve, but that's a different argument.
- barrkel 5y ago
  I think "tidy up" is another phrase for integrating an overly local change. No more than if you're repairing some damage to a wall, you want to work the repair into the surrounding area rather than just infilling and spot painting the exact area of damage. Architecture is often fit for purpose when it is initially written, but a change comes along which requires a minor rearchitecture. The overly local change might be to piggy-back some data on an existing structure (which has subtly or not-so-subtly different scope), or add a flag to an existing method. If it's not just routine BAU - adding yet another CRUD handler - it's somewhat unusual for a slight adjustment in design to not be desirable, IMO. My argument isn't for architecture czars or so-titled architects to be in charge of planning changes. It's that local changes often don't include enough rearchitecture because the person making the local change doesn't have the time to try and see the bigger picture. They just need their feature implemented, their bug fixed, their OKR satisfied. I didn't opine as to a solution, but if I had to, I'd say (1) ensure modules have clear ownership who is / are invested in long term code health, and (2) ensure modularity is crisp and sized small enough that a person or a very small team could rewrite a module in a few months. This isn't enough - there's higher level complexity in the interaction between modules - but it's a start.

OliverM 5y ago

Do you know of any external, authoritative studies demonstrating this? I know it's true from long experience of seeing it happen repeatedly, but I'd like to point at something that can justify a 'refactoring sprint' or something like that to try tackling the impact of this pattern. The other justification is that clean refactored codebases are quicker to change, but it's a difficult sell.

adamkl 5y ago
Maybe not exactly what you’re looking for, but this is a classic paper on the topic: http://laputan.org/mud/ http://laputan.org/mud/

codeflo 5y ago

Very true. Some things I also noticed: Changes tend to be made higher up in the stack, ultimately the UI, because that has a lower risk of breaking something else. This gets very messy very fast. Bugs in shared code tend to be worked around rather than fixed because other code might depend on those bugs — which quickly becomes a self-fulfilling prophecy. Some functions/methods seem to be natural magnets for these overly local changes, and as a result, can wildly grow in size over time. I once analyzed how a 50-line function had grown to 5000 lines over a few years in a series of individually justifiable changes. All of this is a downwards spiral that’s very hard to stop once it has started. “Refactoring sprints” and other heroic efforts sadly seem to have little impact in such an environment if they don’t also radically address the engineering practices that lead to the situation.

hobs 5y ago
The key is the last sentence, its like someone who scheduled a liposuction every year or two to deal with the problem of eating 12 pizzas every day.

cesaref 5y ago

The other side of the coin though is that when you are too close to your code, you can't see some of the refactoring patterns which will simplify it. Fresh eyes bring this to the party. So as ever, a mix of approaches, competencies and knowledge give the best result. And I disagree about this being what goes wrong with architectures. From my experience this is more to do with entropy than anything else. It takes a continual input of effort to 'tidy up' change to keep things looking neat, and this is often ignored or under-estimated until it's too late. The other reason is when the architecture isn't fit for purpose so has to be bent to fit around the problem it's being used to solve, but that's a different argument.

barrkel 5y ago
I think "tidy up" is another phrase for integrating an overly local change. No more than if you're repairing some damage to a wall, you want to work the repair into the surrounding area rather than just infilling and spot painting the exact area of damage. Architecture is often fit for purpose when it is initially written, but a change comes along which requires a minor rearchitecture. The overly local change might be to piggy-back some data on an existing structure (which has subtly or not-so-subtly different scope), or add a flag to an existing method. If it's not just routine BAU - adding yet another CRUD handler - it's somewhat unusual for a slight adjustment in design to not be desirable, IMO. My argument isn't for architecture czars or so-titled architects to be in charge of planning changes. It's that local changes often don't include enough rearchitecture because the person making the local change doesn't have the time to try and see the bigger picture. They just need their feature implemented, their bug fixed, their OKR satisfied. I didn't opine as to a solution, but if I had to, I'd say (1) ensure modules have clear ownership who is / are invested in long term code health, and (2) ensure modularity is crisp and sized small enough that a person or a very small team could rewrite a module in a few months. This isn't enough - there's higher level complexity in the interaction between modules - but it's a start.