LEGACY ON RAILS
Have some #vintage #oldtimer #classic rails app?
Why does software become „legacy“?
Many have tried to discover ways to prevent code from becoming legacy. Professionals have written books on principles, best practices and design patterns that can help programmers keep their systems clean. But even the most disciplined will create a mess from time to time.
We know the main problems that lead to legacy code. Therefore we can provide guidance, tools and patterns, which can help you to work more effectively and confidently with it. Or we can take it off your hands completely.
The cost of legacy
Many legacy systems have reliably served the needs of their businesses. No matter how coupled the underlying code is, the application is generating value and your business processes depend on it.
Old code doesn’t need to be thrown away. Still, complex, difficult to change code is a problem. Especially changing requirements are a big deal regarding legacy code, which results in two main issues:
● In legacy code, it is particularly hard to come up with estimates that are meaningful.
● Even the simplest code changes take
a long time to implement.
● It seems like no amount of time is enough to understand everything you need to make a change.
● It is often intransparent how much of the existing behaviour is at risk when changes are made.
● How much misbehavior can you afford if changes are risky?
● How will you know if you haven’t broken anything?
Rewrite vs. Refactoring
We can help you decide if it would be rational to refactor a big mess instead of starting from scratch. Because a rewrite is not necessarily the cheapest option.
As a rule of thumb, if the application is big and working (mostly stable) in production, an incremental rewrite of the most critical parts is a reasonable strategy. Rebuilding piece by piece will preserve the information which got lost in complex code and the previous investments.
We did a presentation on the topic to show how we work
with legacy apps. You might want to take a look at it.