This article considers the perils and pitfalls of attempting to rewrite your RPG application from scratch. You need to carefully consider the big rewrite option from every angle-it is destined to be the worst step you can take.
We’ve discussed persisting IBM i RPG applications with many customers. When discussing rewriting the application, the most common reasons we hear for wanting to rewrite the organization’s software are:
Our current code is awful.
We can do such a better job this time.
We used the wrong programming language the first time.
We can make it faster and add more features.
We didn’t understand what we needed then and we do now.
Asking your programmers if they should rewrite your software is like asking your waiter if the special of the day is any good. The answer is predictable and lacks objectivity.
Considerations for rewriting your software shouldn’t be programmer-driven, they should be business-driven. The questions that need answered in the planning stages aren’t what new programming frameworks to use, rather they should address issues such as:
How quickly can the application generate an ROI for us?
How will we know the new application is 100% correct?
How can we best budget resources and create a realistic timeline?
Will the new version persist our ability to keep our customers and business partners happy?
A rewrite is more than writing code
The task of rewriting software, especially decades-old software without any written documentation, isn’t just about writing code. In fact, writing code is the easy part. But before code is written, you need determine things like:
How are you going to test your new software? How will you know that it works?
What are the software’s requirements? This needs to be created in detail, with user stories and a clear picture of the data flows and processes.
What is the timeline for rewriting the software?
What resources do you need (ie, programmers, tools, servers, etc)?
RPG programs don’t live in a vacuum. How, and with what, will you replace the supplemental parts of your system (ie, EDI, telephony, job scheduling, et al).
Estimating the time a rewrite takes
In almost every case, the timeline for delivering an enterprise application rewrite is woefully out of touch with reality.
It’s very likely, almost assured, that the team that would rewrite your RPG application has limited knowledge of that application. It’s critical that this team fully understand the scope and complexity of the original application. Even armed with such knowledge, it’s very tough to create, and even tougher to adhere to, a delivery schedule. In most cases, and with the best intentions, the timeline for delivering an enterprise application rewrite is woefully out of touch with reality.
Don’t let anyone tell you otherwise!
The Mythical Man Month is a highly-respected book that every technical manager should read. Although the book is many years old, its messages and wisdom about project management and herding programming teams remains on-target and well-aimed. It is highly-recommended reading for critical decision makers.
What about your existing database?
Another very important question to get answered before you green-light a large rewrite project is: How will you migrate and refactor your database and ensure its veracity?
Moving your IBM i database for a new application isn’t just a matter of copying data from one database to another. It’s almost a certainty that your existing database needs to be refactored and cleansed before any new software can be written. This alone is enormously challenging and absolutely cannot be overlooked. The challenge of moving your database gets even more imposing when you consider that it is a moving target. During the many months of writing new software your database will undergo typical maintenance and changes (ie, keeping up with changing regulations).
Identifying what can be rewritten
Identifying the components that can be rewritten doesn’t directly solve the challenge of what to do about your core RPG application. However, replacing anything you can identify as not providing a core facility to persisting your unique business value helps make the challenge of replacing your RPG system easier.
An IBM i RPG application is very often a monolithic, do-everything application. Most of these apps grew up in the very early years of business computing-well before the days of a plethora of third-party packages or today’s cloud-based solutions platforms. Because most AS/400 shops had RPG programmers in the early days, it was natural for those programmers to write solutions that weren’t just business-specific, but also write those that did more general-purpose work such as general ledger or accounts payable.
An eternal struggle exists identifying what is an independent component in enterprise RPG applications: most components in an older RPG system have levels of vertical interoperability with other components. It’s very common for a mostly generic component to reach across and directly affect the inventory component. When you do find this “fence-jumping,” the cost of decoupling and reengineering alternative integration with third-party components determines if these components can be replaced separately or should be considered a core part of your RPG application.
A tough call
Rewriting enterprise software is a challenging, long-term endeavor. You need to investigate this alternative from every angle and have very realistic expectations. While a big rewrite isn’t guaranteed to fail, the odds are it won’t succeed. It will not only waste money, but more importantly, time.
These articles provide outside perspectives on the perils of The Big Rewrite: