In this sixth and final episode of exploring why Application Modernization projects fail, we are looking at how the lack of processes and tools can contribute as a cause of project failure. For a recap of our previous five episodes, please visit our blog: https://aspeness.com/blog/.
With all the challenges associated with app modernization, why take it on if the application is stable and well supported? When two groups of stakeholders are asked this same question, the responses are quite different on the surface. Executives state that we must “deliver more application innovation,” while application architects and product leadership cite a focus on “improving software development velocity, consistency, adherence to adopted architectural patterns, performance, testability and ease of maintenance.” These answers reflect two sides of the same argument regarding the organization’s goals: innovation is essential for achieving business objectives – capturing new customer and keeping existing customers happy, but technical debt, which hinders software development velocity, is the biggest barrier to innovation. One affects the other. The main objective then should be to improve all of the technical, quality assurance, cybersecurity and operations-related elements of the software quickly so that innovation can also immediately accelerate, but how?
Our research has uncovered that a big constraint for app modernization teams is the lack of standardized processes and tools that are available to assist the team in modernizing applications. Almost all app modernization projects use a brute force approach to modernize the application – wading through mountains of code and modernizing one object or module at a time, but inconsistencies within the code, code duplication, outdated libraries and dependencies, and poor code quality, make this process long and cumbersome when done manually. If technical debt is the barrier to accelerating innovation, then the current process of app modernization – the manual and disconnected approach to modernizing today’s enterprise applications – is the barrier to accelerating the removal of technical debt.
It would make sense then that we need a new approach. An approach that will leverage standardized processes and tools so that technical debt can, not only be paid off, but paid off quickly. Further, the net result of any such endeavor should approach as near a “future proof” posture as is possible (organizations don’t want to have to go through another significant app modernization effort again). But before we get into how an organization can achieve this new development nirvana, let’s explore this term of technical debt a little closer because it means different things to different people. If you were to ask 10 different people for a definition and examples of technical debt, you would likely get 10 different responses. To some, technical debt is not a tangible thing, it’s more of a feeling or frustration they have without having a precise idea of where that feeling comes from. To Software Architects and Engineers, the term generally means that the released software is the culmination of shortcuts taken and sacrifices made due to customer or aggressive schedule commitments and also includes a recognized jumble of very inconsistent coding styles, standards, libraries used, etc. introduced over time (usually referred to as “spaghetti code”, or more simply just “bad code”, serving to create numerous ongoing development and maintenance challenges that always get bigger over time – more on bad code a little later). To Product folks the term means that their roadmap just took a schedule hit and they’ll lose time with no released features because of it. Last, when the business stakeholders get involved, it gets worse. They remember the last time they agreed with a tech-debt focused product release only to find the team underwater again a short while later. When business stakeholders don’t want to grant a tech debt sprint or release because they saw with their own eyes that the last one improved the team’s capacity zero percent, how can the technical team expect them to agree to another one?
Is Technical Debt just “Bad Code”?
So, is technical debt just bad code? Yes and no. Some technical debt is always related to bad code or bad architecture (did I say that out loud?). But saying that all technical debt is somehow associated with bad code sets up traps we can fall into. These traps include:
- Convincing ourselves that the previous developers just weren’t very good at their jobs. But maybe the code was written this way for a reason. Simply labeling technical debt as bad code doesn’t afford the opportunity to dig deeper.
- Allowing ourselves to believe that if our team just wrote good enough code or adopted the latest popular framework, we wouldn’t have technical debt at all. There’s no need to revisit, document, or test this code; it’s just that good. A year later, we’re back to where we started.
- Conflating two ideas such as: “this code doesn’t match my personal preferences” with “this code is a problem”. While this may be true, it is much more likely that this “bad code” was written in a way that was different than the way the current team would write it. After the engineering team finishes their caffeine-infused refactoring bender, the code is no easier to work in than it was before; it’s often just different. This is especially true when of the application are focused on. The end result of this approach (usually due to time and resource constraints) is one where the full spectrum of existing technical debt is attempted to be solved by slowly chipping away at the problem which…never actually gets the complete job done.
So, if we can’t agree on a single definition of technical debt or whether we should even use the term as something to eliminate, what should we use? I would suggest using a metric that’s more tangible and measurable such as maintenance costs of maintenance level of effort (LOE) of the application. How much time, effort or expense are developers spending on tasks that are not adding features or functionality to the application? How much time, effort or expense are being spent just maintaining the application in its current form? In addition, we should also track how fast this value grows over time – because it likely will never shrink on its own. The faster our maintenance LOE grows, the more challenges we can expect as an application team over time. No growth means that the development team can maintain the system with the same number of resources into the future. So, what is your maintenance LOE, how fast is it growing and what can you do about it?
Aspen Warp Drive Engine™
Aspen is the result of more than a quarter century of trying to solve the age-old questions in IT – how can my team go faster, produce more features, improve quality, and lower costs? Using traditional software development processes and tools – Agile included – when trying to modernize older business software doesn’t get the job done. So that is why we created Aspen’s Warp Drive Engine™.
- Creation of Application Objects. Aspen’s Warp Drive Engine™ creates all the source code necessary to run your legacy software application. The code that is produced is standardized, which makes it easy and faster to enhance in the future. It is also consistent, which makes it easy to support and the code is hardened which makes it secure. Aspen can future proof your application, reducing the technical risk of an app modernization project and significantly improving productivity, all in a few minutes.
- Migration of Business Logic. Database business logic is extracted and placed into the application, exposing it so that it can be enhanced in the future. Multi-logic instances are consolidated so that the application is consistent, making it easier to enhance and support in the future. You can even add your own custom business logic.
- Creation of Automated Tests. We create all the automated integration and unit tests that the application needs, and we subject your modernized application to third-party testing via SonarQube™, giving you confidence in the quality of the application produced (cybersecurity testing included!).
- Creation of a Suite of APIs. We create all the APIs that your modern application needs in both REST and GraphQL formats. The APIs are now the single gateway into the application logic and data tier making it much more secure.
- User Interface Development. A Starter React and Tailwind-based User Interface is created during a job run, allowing you to use the application immediately and fine tune the user experience over time. The user interface uses all recently created APIs, making it secure and consistent.
- Creation of CI/CD Deployment Packages. We provide you with a complete deployment package for Azure and AWS (coming soon) improving productivity. You can choose to host your application with us, until you’re ready to move it. The code is yours, there is no vendor lock-in with Aspen, ever.
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.
