I stated my carer developing systems in an enterprise setting but have since moved into the wonderful space of companies transitioning from startup to enterpris

I stated my carer developing systems in an enterprise setting but have since moved into the wonderful space of companies transitioning from startup to enterprise. So I’ve worked a lot in this space, and while I’m not sure that I necessarily agree that old complex software is unmanageable legacy, there is a lot of truths in this article. In my experience software doesn’t really have to be “legacy” to encounter these issues. In fact a lot of 30+ year old systems are both better and more maintainable than things developed within the past 5 years. Which is probably an interesting case on its own, but let’s keep on topic! The way I like to handle these systems is to slowly transition things into “microservices”. I put in in quotes because it doesn’t necessarily have to be what many think of when they read the word “microservices”, and in truth they aren’t at all since they often build upon complex shared data models with all the “fun” that comes with that. Eventually I like to build things in to actual microservices, but it’s often a loooong if not impossible struggle to get there within most organisations which view IT as a cost center on par with HR but without the communication charms. Anyway, what I like to do is to separate complex business logic into their own “microservices” so that anything related to X lives in a single smallish services instead of a big complex system. One which is example is how we’ve got a “budget upload and computation”, a ”liquidity (not entirely sure that’s the correct English word)”, and, a “bank account” service all of which used to be part of this huge complex system, but are now separated completely in terms of the responsibility for their particular businesses logic. Eventually this breaks complex systems into a ton of minor services, which comes with its own set of issues and is obviously against a lot of what you’re taught in academic computer science because often you’ll have similar code in multiple systems, but it’s sooo much more maintainable and it’s so much easier to move fast and implement what the particular teams in an enterprise organisation needs for their particular business logic. In my example, we’ve gone from five teams having to wait literal months for changes to being able to implement them within a week, and often the same day they are requested. We’ve also lowered our incident reports on problems from less than 60% to above 90% each month. I’m not sure why we call it lowered when higher is better, but whatever.