Your organization has taken the leap and chosen to modernize your existing COBOL monoliths into Java-based application services, ready for the cloud.
Your team plots out a journey toward success. Rather than taking a risky big-bang approach, each incremental release on the road toward modernization is prioritized and scheduled to save costs and capture value that finances the next step.
The automation factory starts to chew up old tables and churn out Java. The destination is in sight. Cue Barry Manilow singing, “Looks like we made it!”
But hold on, how do we define success for the Java code we’re getting back? Should the modernization project move fast and take less time, thereby providing better ROI? Should it be of impeccable quality? Or should it accommodate maintainability for change?
Must we choose between these options?
Why do we want maintainable Java code?
In a perfect world, once each modernization step was completed, you would never need to go back and revisit those deprecated old COBOL stacks to rebuild that functionality ever again.
Taking this a step further, you would also rather not have to entirely rethink and refactor your new Java codebase down the road either.
But like it or not, change will eventually come for your code.
No real business developer lives on an island with their own air-gapped deployment server. Things will always change within the environment, and the needs of target users will also change. At some point, any application may either consume or be consumed by another application, whether as a partner service or as part of an acquisition.
Whether the Java code is greenfield developed by the team to functionally replace legacy applications or converted from COBOL by an automated modernization solution like CloudFrame, you will still want the resulting Java code to be flexible enough to accommodate change and talk to other services, which is part of the nature of any modern system.
Maintainable code means that when a bug needs to be fixed, or updates need to be made in the future, a developer who did not write the code should be able to open it up, find it well-formatted and “clean,” understand its structure, and figure out how to make effective adjustments.
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” – John Woods
The need for maintainable code comes from team dynamics – whether intra-team developers are actively working on the same code in an agile or pairwise method – or extra-team settings where one development team hands off code to another development or operations team for maintenance or production…
— Read the whole BrainBlog on CloudFrame here: https://cloudframe.com/is-the-java-modernization-destination-quality-or-maintainability/
Comments
Comments are closed.