Building on legacy systems instead of starting over
The system nobody wants to touch any more and without which the business stops. I touch it.
How I work
The first instinct is almost always to rebuild. That is expensive, takes longer than planned, and throws away knowledge that now exists only in the old code. So I start differently: read it, write down how it works, put tests around the parts that matter. Only once there is a safety net does anything get rebuilt, and then in pieces that can go live one at a time.
Java on an old version, PL/SQL with no documentation, a manual from 2009 and a colleague who retired and would rather not be called. That is the normal case, not the exception. What usually comes out at the end isn’t a rebuild but a system that is maintainable again, where the next request takes a week instead of a quarter.
Typical jobs
-
01
Getting into someone else’s code and writing down how it works
-
02
Putting tests around the flows that must never break
-
03
Carving out one piece and rebuilding it as its own service
-
04
Lifting language, framework and database onto supported versions
-
05
Containerising an application so it survives the next server move
With what
Java including older versions, PL/SQL, PHP, Docker for encapsulation, automated tests, step-by-step migration
Where you can check this
The services overview has a sounding lead you can lower through the layers of an application. Right at the bottom you find this exact case, and it isn’t meant as a joke.
MoreOften goes with this
All servicesWhether it’s a specific project or just a question for now, write it down the way you’d tell a colleague. You’ll get a reply from me, not from a mailbox.