Do you have, or work for company that has a legacy codebase, if you have one or more of the following then, my condolences, you do:
- PHP version 5.3 to 7.0
- Lack of documentation and/or application knowledge
- Struggle to keep the application alive and/or poor performance
- Seems like no matter how much work is done nothing moves forward
- There is one person on your tech team who is the 'source of all knowledge'
So you have a problem. But you're convinced the problem stems from the tech team focusing on the wrong problems and fixing seemingly endless, unnecessary obscure stuff that you don't really understand.
I know, it's very frustrating. But unfortunately, your application has fallen into the legacy trap. You might well be aware of how woeful the state of you application is in and can't decide on how to allocate your development resources.
Should I split the team and create a new application from scratch or should I get the whole team to focus on refactoring and fixing what we already have.
But either choice will mean a slow down or complete halt of feature delivery. hmm. you're in a bit of a pickle and the application errors and crashes keep pouring in like a tidal wave of bad news and stress and the delivery targets are consistently being missed. (not a good look if you're eyeing up a promotion )
Well ideally this is where I come in. Like an impoverished gigolo with an expensive cocaine habit, shameless and blatant service promotion is not above me. No, seriously, give me a call (+420 608 187 548). But the question then becomes what on earth can I do to change this dire situation?
- Codebase Analysis: First we need context, we need to find out what we are dealing with and how fooked you application is. This is done in the form of a code base analysis, where we find and report all the applications pros and cons.
- Set A Goal: Set a clear and achievable objective and create subsequent smaller steps to attain this main objective. This might be, the application is beyond saving, let's start fresh, but now the decision is based on comforting data, not on a whim.
- Break the cycle: There is a reason the application got into this state in the first place. you can make an omlet without breaking eggs. Well you can can't fix a legacy codebase without breaking some programmers... bad habits. (in all seriousness this is generally the most difficult step and can be difficult as change normally is) This comes in the form of setting up new practices and enforcing them, ensuring code quality and standards are adhered to, reviews are given and refactoring is done.
Now that I've put myself out of a job, it's important to note that legacy migration experience can be useful (of course, I would say that) and can save a considerable amount of time and money.
I hope by now you found value in this article, but more importantly you've realised I'm looking for work, give me a call and I'll give you a free consultation.