Refactoring is Not the Same as Re-Designing
I had an interesting conversation with another developer today. He stopped by to tell me a problem he'd run into with the part of the code he's working on. He knew what he wanted to do, but he wasn't going to do it. He felt that it was better to give the users something as soon as possible, even though it was wrong, than asking them to hold off a while and build the right solution to the problem. It reminded me of the term I'd heard from another co-worker: Software Debt.
I found this article that does a reasonably good job of describing it. It's something that you have to be careful of every single day you write code. It's easy to hack something together and then say "I'll fix it later". The hard part is actually doing it.
This developer I was talking to was convinced that the solution to the problems created by these hacks added for immediate release was simply Eclipse. Yup, since Eclipse can refactor code, it's easy for him to go back and change everything about the code when he goes back into it later.
Now I'm not saying Eclipse isn't a great tool, but it's a refactoring tool, not a re-designing tool. And going back into the code presumes that you're back in the code. What happens if you don't need to go back in because the hack is only used once every six months, and at the time you notice that it's time to fix it, it's too late, and you're once again in the bind that something is expected by the users.
Rather than argue the point, I said "OK", and he's off to do the coding as he sees fit. I'm not his supervisor, he doesn't report to me, so it's a collaboration. In that vein, until it's my problem, it's his problem, and if that's the way he wants to handle his problems, then that's OK with me. In the end, we both know that it's wrong, and the right thing to do is to build something that's close to right (as close as possible), but still delivering close to the same timeframe as the hack. Get close, then come back and work it into the better solution.
But it's nieve in my book to think that it's just a matter of a little refactoring to change one system to another. Maybe it is that simple. More often than not, it's going to be some re-design as well as refactoring. It's not going to be something that's done unless there's a pressing concern to do it. While it's certainly possible that he's going to fix up this hack in the coming weeks, it's far more likely that much of it will stay and then some day we're going to be under so much software debt that we're going to be forced to throw it all away.
It's a shame. He agrees it's not the right solution, but is doing it anyway. Too bad.