Dealing with legacy is more than the right architecture

So, picture this: you're stuck working on this old, massive monolith, and for years, it's the same old story – we gotta fix this, 'cause delivery's crawling, and keeping developers happy (or even hiring new ones!) is a nightmare.

I bet a lot of us have been there, or will be. Let's say we're at that point where we're finally thinking, 'Okay, we need a solution.' What do you even start looking at? Deployment? Performance? Breaking things into smaller services? The code itself? There's a ton to think about. I know as developers, tech leads, and architects, we love to solve problems by looking at them through a technical lens. And I'm not saying you shouldn't think about all that, but here are a few additional things you should take into consideration:

• Don't include things that aren't required. If you're bringing in a new architecture, you don't have to refactor all the code. That'll just slow you down and make things riskier. Just tackle the bits you absolutely have to.
• Focus on improving the parts of the system where everyone's struggling the most. That struggle means (1) developers are frequently changing this code, and (2) the design is far from being supportive in their work. You'll see results faster and make everyone's lives easier if you will start your journey in those places.
• Learn from those who've been there. The harder the problem, the more ways it can go wrong. Developers love solving puzzles, but those who've done this before know the pitfalls and can save you from headaches you didn't even know existed. Don't reinvent the wheel.
• Get everyone involved and delegate as much as possible. Big projects need lots of hands. I know being the 'all-knowing' person in the project feels great, but it'll bite you when things go south. And let's be real, something will go wrong.
• When you pick a technology or approach, consider what your team already knows. The coolest new thing might need a ton of training, and changing people's habits is even harder. It's difficult to learn new things, but it's even harder to unlearn the practices we already follow. Sometimes, the 'not-perfect' solution is better if your team already knows it.
• And remember, your project isn't that special. At least not when it comes to development and design. Use the recommended techniques and approaches. CI/CD isn't the enemy, and automated tests don't bite.

Big decisions aren't just about the solution itself. You've gotta think about how you're gonna build it, keep it running, and who's gonna be doing all that.