The code nobody dared to touch now grows one piece at a time

Where the application started from

I inherited a web application used every day by several companies for their work. Over the years it had grown with a separate code branch for each company, while the original version had stood still.

Why every change was risky

Every change to the data was a leap in the dark. These were the weak points:

• Locks left by the previous developers: removing certain options made the data impossible to edit.
• Addresses hard-coded in the code and actions that failed silently.
• A list that showed a maximum of 10 items.
• No staging environment, no tests, manual releases via FTP and a local database different from the production one.

How I made it changeable without rewriting it

I chose to keep the application and change the method for modifying it.

• Scripts that can be re-run. Data changes go through scripts that can be re-run without causing damage, with a check before and one after.
• Tests on a copy of production. Every change is first tested on the real data, in a copy.
• A guide for every release. It states the commit and the expected figures to check afterwards.
• Saved documents are left untouched. The calculations made at the time stay as they were.
• Existing data reused. The new parts use the data that is already there, so a changed piece of data applies everywhere.

On this foundation came the new features: a new user role with its own permissions, percentage-based data changes with a preview, cascading calculations, documented APIs, integration with a company's management system.

What has changed

• New parts added without duplicating data.
• Dozens of checks verify that a change hasn't broken anything.
• More than 100 automated checks introduced on the new role's permissions.
• Complete API documentation, checked against the code.
• More than 100 groups of data realigned with a script tested first on the copy.
• Dozens of client requests handled.

What you can take away

• Before rewriting inherited code, it pays to make the way it is changed reliable.
• Every data change must be able to be re-run without causing damage.
• Always test on a copy of production, with the real data.
• Documents already issued are not recalculated: they stay as they were.

Details have been changed to protect the client's confidentiality.