If you’re refactoring something – do it iteratively.
Recently I was refactoring some code, it was time to pay off some debt. We have modular monolith and it appeared that one module was clearly a part of another, they just ping-ponged themselves all the time.
I was convinced that it was trivial. Communication from and to the module is done entirely via the module’s API. So it’s enough to move all files from the obsolete module to the other one and done. Right?
Technical debt is a tool – use it, but use it wisely.
Technical debt is cool. Am I crazy? No, I think it’s a great feature (yes, feature) of agile development. Let me explain.
Technical debt is there. We can safely assume that in the very moment you finished a feature and pushed it to production – it’s debt. Best code is no code. But let’s talk about intentionally creating it.
Let’s say you like to write good, readable and tested code. You take care of DDD, use best practices, create caches when necessary. But then business has an idea for a feature, and they aren’t sure if it’s gonna work but they wants it fast. If you’d try to make this feature as you like, as your engineering soul tells you, you’d say “ok, give me a week or two”. There are disadvantages to that approach.
It was a while since the last post. At first, I had no idea what to write about. My post about string performance comparison was quite a success, so everything seems to go pretty well.
But from about one and a half months I simply… don’t code at all! It’s because we have significant changes in our company. Teams started to be interdisciplinary, that means to developers joined marketing, analysis, communication guys. And I was responsible for helping people understand the change. In fact, I was true, full-time Scrum Master…