Incentives Not To Invest In Structure
In which we meet the good-hearted people opposed to progress
I ran across a surprising opponent to improving structure: those interested in improving structure. How does that work?
Well, let’s say you have a group of people who want to make things a lot better. Micro-services advocates are today’s cliché example.
You have some code. It’s a mess. You want to tidy. Cause for celebration, right?
No, you get pushback. “Don’t tidy that. We’re about to replace it.” “Don’t tidy that. We want all the mess in one place.” “Don’t tidy that. It won’t make any difference.”
TF? suggests improving in small, safe steps, then making those steps so frequent that it looks like you are running. Not everybody has the same incentives, though. When you get pushback, remember that those pushing have different incentives than you do. They aren’t (likely) evil or stupid, any more than you are. Mostly just tidy anyway, but don’t be surprised or defensive.
I find a lot of times there's push back from developers who don't TDD, and they definitely don't do incremental test and commit.
I find tidying to be entirely about economics. If code is not getting in the way of my work I just don't touch it. Getting in the way could be where I need to understand it to make another change, in which case I may refactor it. It could be where it's core to what I'm changing, and it's difficult to read, inflexible, or whatever, and that too gets in my way. But if it ain't getting in my way, I usually leave it alone. I know that sometimes people like to tidy just because something looks bad, and I've seen projects take a very long time because of that. Code *always* looks bad, and you can actually over do it. :D
This will not work well. When you replace the code, you will need the experience from the previous refactoring. That will make a difference.