How do you evaluate and refactor software design to reduce complexity and technical debt?

Addressing complexity and technical debt is an ongoing process, rather than a one-time activity. Software systems are constantly evolving over time. Adopting an iterative approach to identifying the sources and addressing these issues helps maintain the overall health of the system and promotes continuous improvement. While it is important to identify and address existing sources of complexity and technical debt, it's equally important to establish practices that prevent them from accumulating in the first place. Incorporating design principles like SOLID, implementing coding standards, and embracing test-driven development can help create a foundation for maintainable, extensible, and high-quality software.

Understanding the class of technical debt in your product helps prioritize the right issues. 1. High churn code areas need to be maintainable by addressing simplicity, readability, documentation etc. 2. Critical code paths that affect high level product quality w.r.t reliability and performance. 3. Learnings from Incident postmortems and customer feedback - Prevent issues or detect early, validation and monitoring gaps. 4. Quick refactoring, deduplication, up-to-date dependencies, dead code removal 5. Violations detected by code analysis tools. 6. Business impact - reducing operation cost 7. Issues impacting developer efficiency

Tackling complexity and technical debt often involves making trade-offs between short-term benefits and long-term sustainability. Prioritizing which issues to address first is crucial to ensure that resources are allocated effectively. There is usually a constant tussle between releasing new features vs investing in tech debt. In my experience, what I have found helpful is to ensure that decision-making is guided by a combination of factors, such as business value (reduction in operations/ better response times, etc.), risk of not addressing the given tech debt, and the estimated effort required for each issue.

One thing I've observed is that the the need to deal with twin evils of unnecessary complexity & technical debt usually stems from a prior failure to observe due engineering rigour. The time vs cost vs quality debate will rage forever no doubt, but if there's one time you should hold those costly principles dear, its when you're trying to fix prior problems.

I would like to quote a real world example. Microsoft's .NET Framework has been widely used for building Windows-based applications since its release in the early 2000s. However, as the technology landscape evolved, the need for a more modular, cross-platform, and efficient runtime became apparent. Microsoft responded to this by developing .NET Core, an open-source, modular, and lightweight version of the .NET Framework. This shift involved significant refactoring and redesign efforts, which allowed for improved performance, better support for containerization, and the ability to target multiple platforms. This initiative allowed Microsoft to target macOS, Linux, and mobile platforms and expand their market reach.