In the fifth episode of exploring why Application Modernization projects fail, we are looking at how the application complexity can contribute as a cause of project failure. For a recap of our previous four episodes, please visit our blog: https://aspeness.com/blog/.
Refactoring, often seen as the cornerstone of app modernization, comes with its own set of challenges. Executives frequently highlight the time-consuming nature of the process, while application architects emphasize both its importance and complexity. Both perspectives are valid, as refactoring would traditionally involve a significant manual effort. Analyzing millions of lines of code and thousands of classes can take months if not years. This is before even considering the design, rearchitecting, testing, and deployment of APIs or microservices. Executives desire quicker results (usually tied to business value), but architects face the daunting task of untangling numerous dependencies, identifying the most problematic areas of the product technology stack and prioritizing work without compromising schedules, budgets, sales opportunities, customer satisfaction, etc..
Technical debt may accumulate because enhancements to the application, particularly older applications, didn’t follow recognized best practices or software development principles. The SOLID software development principle is one of those time-tested rubrics for creating quality software almost any enterprise application would benefit from. Originally developed by Robert C. Martin (colloquially known as “Uncle Bob”), he introduced the collection of principles in his 2000 paper Design Principles and Design Patterns about software rot which later was coined SOLID around 2004 by Michael Feathers. SOLID was a proposed way of thinking specifically about the quality and maintainability of object-oriented (OO) programming:
- S – Single Responsibility Principle. Each class should do one thing and do it well.
- O – OpenClosed Principle. A class is Open to being added to but Closed to destructive changes.
- L – Liskov Substitution Principle. You should be able to substitute one thing for another if those things are declared to behave the same way.
- I – Interface Segregation Principle. Don’t show your users more than they need to see – smaller, purpose-based interfaces are more useful than single, general-purpose ones in the long run.
- D – Dependency Inversion Principle. Depend upon abstractions, not concretions.
When these principles aren’t followed (or are followed haphazardly), the result is what’s often called spaghetti code where maintenance, performance, scalability and desire to extend existing or add new functionality suffer). Some examples of manifestations of spaghetti code include:
- Tight Coupling. Tight coupling, also known as strong coupling. Coupling is the degree to which each program module relies on each one of the other modules. If making a change in one module in your application requires you to change another module, then coupling exists. Tightly coupled modules are difficult to reuse and is hard to test.
- Testability. Testing should not be hard! No, really. Whenever your development team doesn’t write unit tests because they don’t have time, the real issue is that their code is bad.
- Premature Optimization. Donald Knuth said: “premature optimization is the root of all evil. There is only cost, and no benefit”. Optimized systems are much more complex than just rewriting the code to simplify it.
- Duplication. Duplicated code is bad because changing the code in one location but not another (you may not know there’s another method that does the same thing) could introduce unexpected behavior (read bug), so please Don’t Repeat Yourself (DRY), and also Keep It Simple, Stupid. Be lazy the right way – write code only once
So, what keeps organizations from paying down their technical debt and modernizing incrementally over time, so that the complexity and risk is reduced. In short – the business. This required maintenance is often a hard sell in some organizations, which would rather spend resources on building new functional capabilities to meet customer demand, than pay for work that doesn’t necessarily bring them anything new. For many companies, the number one thing keeping them from retiring technical debt is the fact that the business wants new capabilities and additional functionality to keep up with business requirements. CIOs are now one of the most strategic roles in the company, because they need to help organizations make this trade off. Not only are they tasked with maintaining the business, but they are also often tasked with building the functionality to give the company a competitive advantage.
Aspen Warp Drive Engine™
The Aspen Warp Drive Engine™ modernizes your legacy software application based on the SOLID development principles. As result, your application is easier and faster to enhance in the future. The code is also consistent, which makes it easy to support after your application has been upgraded. Finally, the code is hardened which makes it much more secure to cybersecurity threats. Aspen can future proof your application, reducing the technical risk of an app modernization project and significantly improving productivity – and we can accomplish this faster than anyone else in the world.
If you would like to learn more about our solutions, contact us at info@aspeness.com or visit our website at www.aspeness.com.
Todd Ingersoll
With over 20 years of experience serving multiple roles inside successful enterprise software and services organizations, Todd has been expressly interested in successfully overcoming app modernization challenges. His first-hand experience and dissatisfaction with the limitations and business impact of the traditional options of application modernization led him to create Aspen ESS. Aspen ESS was created to give organizations rapid, reliable, scalable, and extendable solutions to challenges with legacy software products and portfolios.
