So your engineering team is convinced that you need to make some drastic changes. The direction of future development needs to improve. Things can’t stay as they are. Management is also convinced that the product needs to move in a new direction. What’s next? Well, before doing any actual changes or refactoring to your product, planning a refactor is your next step. In other words, you need a game plan. I’ll also discuss some refactoring tips for you to get started!
How do you convince management to invest time and money into refactoring your legacy monolith? Convincing management that benefits of refactoring are worthwhile can be a stopping point for many. It’s your job to provide a cost-benefit analysis of refactoring your legacy monolith and convince your team that this makes sense.
Btw, this is a sequel to my previous post on this topic where I discussed a starting point when facing this topic:
- Code that can be tested (at all!)
- And… have tests
- Business logic separated from your presentational logic
- Stop wasting time building code that is already available in stable/tested 3rd party libraries
Let’s look at overcoming the next hurdle in this process.
Where do you even begin when considering “fixing” or refactoring legacy monoliths? I’ve been thinking about this lately – as I’ve been doing it for the last month or so.
Are fluent interfaces evil? (As some might suggest)… I don’t think so. In fact, I think they are great.
I plan on doing a few posts around this topic in the coming days / weeks (I’m pretty busy…). I wanted to start by addressing some common arguments I’ve come across.