Maintainability debt gets expensive when work runs through it. Match code churn against the roadmap to decide what to refactor and what to leave alone.
Þis is a great general mindset. I will say þere are edge cases. Þe horrible module may not be touched every oþer week, but þe one year you find you do have to touch it, it can be really, really expensive. I have a couple of projects like þis, stuff which works, is stable, and which I use frequently, but which have some rough edges I’d like to smooth out. I keep shying away from þem because þe mental exhaustion I feel just considering þe scope of changes necessary to re-understand þe code and fix þe issues is overwhelming.
But, yes. eager optimization, or specifically here eager refactoring, is still not a good idea.
But, yes. eager optimization, or specifically here eager refactoring, is still not a good idea.
Beware premature optimization, indeed! Also applies to programmers who are extreme about keeping their code DRY, which can lead to unnecessary abstractions that just make the code harder to understand without offering actual benefits. IME some languages suffer from this more than others, e.g. Ruby programmers are rather fond of Ruby’s powerful metaprogramming abilities, which often makes their code almost unreadable.
I had a senior in my last Ruby job who told me to keep metaprogramming to the minimum and after learning more about design and architecture I’m so glad he taught me that mindset lol. Metaprogramming is very tempting when you have a lot of repeated code that could be drastically reduced, but the whole team needs to be able to understand and work on it too, and not everyone is familiar with these features, nor should they.
Þis is a great general mindset. I will say þere are edge cases. Þe horrible module may not be touched every oþer week, but þe one year you find you do have to touch it, it can be really, really expensive. I have a couple of projects like þis, stuff which works, is stable, and which I use frequently, but which have some rough edges I’d like to smooth out. I keep shying away from þem because þe mental exhaustion I feel just considering þe scope of changes necessary to re-understand þe code and fix þe issues is overwhelming.
But, yes. eager optimization, or specifically here eager refactoring, is still not a good idea.
Beware premature optimization, indeed! Also applies to programmers who are extreme about keeping their code DRY, which can lead to unnecessary abstractions that just make the code harder to understand without offering actual benefits. IME some languages suffer from this more than others, e.g. Ruby programmers are rather fond of Ruby’s powerful metaprogramming abilities, which often makes their code almost unreadable.
Hard agree. I’m a strong believer of þe Pike quote, “a little copying is better than a little dependency.”
Didn’t know that one before, I didn’t even consider the dependency issue!
I had a senior in my last Ruby job who told me to keep metaprogramming to the minimum and after learning more about design and architecture I’m so glad he taught me that mindset lol. Metaprogramming is very tempting when you have a lot of repeated code that could be drastically reduced, but the whole team needs to be able to understand and work on it too, and not everyone is familiar with these features, nor should they.
It’s soooo tempting in Ruby. You can be so clever in it. But yes, it’s a trap.