I am compelled to febreeze every bit of code smell I come across. I often rewrite large sections of working code into better structures, more readable/concise syntax, better naming of variables/functions, etc. and In the process I have at times introduced bugs.
But that isn't enough to deter me.
I feel like I've accomplished something but in reality I have done nothing. It's kinda like cleaning behind the refrigerator. You know it's dirty back there, but it's not stopping the fridge from keeping your food cold.
At my current job I was introduced to the notion of 'past you' and 'future you'. I hadn't really thought about actions in those terms exactly, but the act of doing something today so that in the future when you come back to it you'll be in a better position, is the essence of the philosophy.
I have found that taking the time to rewrite the code that finally works into something that I can explain to myself in the future has paid dividends when I came back to it, and when I have not done that, we'll that can be annoying.
Yup, if we want to beat the analogy further, I would say the constant attention to code "smells" and such is like cleaning behind the refrigerator daily when you see dust has landed. I think there is a great middle ground, where you actually consider the possibility that the improvement to the code will be a net loss (time investment to improve code and time it saves in the future). Lots of books about this, many people don't get the full theories, and instead take the talking points (x lines of code per method, don't do Y, do Z, etc).
Technical debt only compounds if you're building on top of it. A module that is written once and never needs to be modified doesn't get any worse over time. Therefore, once it is working correctly, there is no point in wasting effort to clean it up until it needs to be touched again.
Note that I assume basic documentation, proper naming conventions, and adequate testing are part of "working correctly". Those are the things you do as you write the code initially. It's the refactoring/rework/gold plating that you leave for later, only if you need it.
One thing I'm also guilty of is fixing code that I'm not currently touching. I like consistency and having a project with code from old me (and old others) mixed in with code from new me (and new others) really bothers my OCDness. The problem is that changing working old code in lieu of fixing bugs or adding features is just another form of procrastination.
There is a time and place for code cleaning. If the code isn't something you are already working in, then leave it. If you are tasked to fix a problem or add something to existing code then cleaning it up is acceptable. Keep mind, I'm assuming there are tests written. Nothing pisses off your co-workers more than cleaning up working code and breaking inadvertently breaking something.
I am compelled to febreeze every bit of code smell I come across. I often rewrite large sections of working code into better structures, more readable/concise syntax, better naming of variables/functions, etc. and In the process I have at times introduced bugs.
That's sort of like throwing a punch so hard that you throw yourself off balance.
I would suggest that you take that energy and first write unit tests or a code coverage tool or an assertion framework that doesn't intrude on production. (I've done all of the above, but I may have been "cheating" by using a language with exceptional access to the meta-level.)
This would allow you to refactor with greatly reduced introduced bugs. That would be more like keeping your balance thus staying in a good position to exploit an opening.
This happens to me too, but I try to take a more optimistic look at it. I've found that code that I've written that turned into a monstrosity is code that I'll rarely want to touch again. If I don't want to touch it, then I'm less likely to add (or remove) features, fix bugs, etc.
But if I find the time to clean that code up---make it simpler and clearer, usually---then I find that I'm no longer fearful of touching that portion of code. I'm reinvigorated to fix bugs, add/remove features, etc.
So yeah, while the intangible effect is, "oh I've made the code simpler that really does feel good," I've also found tangible effects because I'm more motivated to work with that code in the future.
> I am compelled to febreeze every bit of code smell I come across. I often rewrite large sections of working code into better structures, more readable/concise syntax, better naming of variables/functions, etc. and In the process I have at times introduced bugs.
I can absolutely relate to that. It has happened that I find code so terribly written that needed to be modified. As nobody on the team actually understood how it was supposed to be working, I ripped it out, and rewrote it in a cleaner way. I knew this may introduce regressions, but I knew the modification I had to make would very likely do the same thing. But if there were going to be bugs, I'd rather have them come from a maintainable codebase.
> You know it's dirty back there, but it's not stopping the fridge from keeping your food cold.
Unfortunately, the more technical debt you accumulate, the more difficult it is to change anything. So, yes, enough dirt will eventually lead to "we can't do X because it's too risky/too much work". Ideally, we should all do some refactoring every week.
I feel the same way, only I usually end up packing up those nice refactorings and tucking them away. I do not want to introduce a live site bug while trying to make things "nicer."
I've had the same problem at times. It's kind of a mental masturbation; adding more abstract structures and more higher order functions.
Need to strike a balance between Get Shit Done and leaving behind code that isn't a pain to maintain.
In fact, often the kind of abstractions I've created when I'm in that masturbatory mode described above, it turns out that the abstractions aren't worth it in the end because they're only used once, and it doesn't actually make the code cleaner or easier to maintain going forward!
Yes, that's my experience as well! I'll carefully design code so that it can be extended and then find out I need to extend it in an orthogonal way I hadn't imagined, and my "extensibility" completely gets in the way. I've eventually just settled on, "build something simple and extend it when needed."
Isn't that what unit tests are for? I seem to recall the original XP practices mandated unit tests mostly as a way to allow the programmer freedom to refactor without fear of breaking code.
This is a great metaphor for software. There is diminishing returns to refactoring and elegance. Sometimes the open source community goes too far (ever try submitting patches to big OSS projects.. Some are ridiculously picky with minor details like code style.)
Code style is extremely important. A lack of consistency with existing code makes both the new and old code harder to work with in the future. And neglecting to maintain a consistent coding style often indicates neglect in other areas, such as correctness and robustness.
I am compelled to febreeze every bit of code smell I come across. I often rewrite large sections of working code into better structures, more readable/concise syntax, better naming of variables/functions, etc. and In the process I have at times introduced bugs.
But that isn't enough to deter me.
I feel like I've accomplished something but in reality I have done nothing. It's kinda like cleaning behind the refrigerator. You know it's dirty back there, but it's not stopping the fridge from keeping your food cold.