31–40 of 78 posts
* NEVER modify existing one. Once you change one line of comment, you own all the code and problem from that point.
* If rewrite is not allowed, then ask huge pay raise for this work. Basically it is not about money, it is about bring everyone on the same page on the status of he existing solution.
* If the above does not work out, prepare to switch to another project, or quit the job totally.
Don't touch anything. Run. There's no glory for you in this.
So the cold reality for this client is that the codebase will have to be replaced over time. You are not trying to escape legacy simply for the lure of something new, you are trying to escape insanity. I would talk to the client about focusing your effort on helping them transition--a small piece at time--to a sane architecture. If they aren't open to that, they aren't your client. I've been a business leader in a po…
1. Get it onto version control. 2. Make sure there is some workable strategy for deploying and testing the code. 3. Ask somebody to provide you with a list of the changes, or else try to create some kind of diff against the original version of the code. If you can see crazy stuff here then find out who did it... 4. Ask somebody what the biggest bugs are? Which things are causing clients the most problems? 5. Try to e…
1. Identify a small and easily separable piece of code (what you woud call a component in a normal system.)
2. Write tests covering every (important?) edge-case of the piece of code you want to rewrite.
3. Mercilessly refactor until it's nice and squeeky clean.
4. Lather, rinse and repeat.
And of course, make sure your client acknowledges that it's a giant clusterf... and is on board with you pulling the system out of the stone age.
Also, if you want to make life a bit more interesting for yourself, get the PHP code's AST and programmatically rewrite existing code to shared conventions for kicks.
What is most important is what are you trying to achieve. Are you trying to make the system as stable as possible at the lowest cost to the client or are you trying to bring this system into a future proof state and the client is willing to pay for that? Personally if I were in your position I would explain to the client that I'm happy to temporarily fix some bugs but long term the system needs to be rewritten. 700k…
I've come to believe that the skill of not rewriting from scratch but forcing yourself to slowly refactor (as per Martin Fowler's definition) existing systems into a proper state is one of the most important skills you can develop.
That way, once you've refactored most of the system (which includes adding tests for all the important functionality) you can indeed confidently rewrite everything. If you do it any sooner than that though, you're in for a world of pain.
I started writing some suggestions but you know what - someone is dumping this on you because they didn't care and their predecessors didn't care, etc. They probably make far more than you for doing far less. The moment you start touching the code, you are going to start being blamed for the nightmare preceding you. It could even affect your career if future employment researches where you worked previously and gets…
Are you working on this by yourself? How long until your employer is expecting bugs fixed and features added?
Yes, by myself. The client so far has been understanding... they've already burnt through several contracting companies, and I think they're starting to understand what a mess it is. But still, they want to see serious progress within a month (eg. large number of bug fixes).
Unless you're can't-pay-your-bills broke and there are no other jobs in your area, the correct response is "I'm sorry. This can't be fixed. It needs to be scrapped completely and replaced with something maintainable. If that's not an option, I'm going to have to resign."
Even if you manage to fix it, it'll still be a pile of crap, and you'll never get the credit you deserve.
On the other hand, if you don't manage to fix it you're going to get blamed.
Zero credit on the upside, major blame on the downside. There's nothing for you in this but pain, my friend.
Are you working on this by yourself? How long until your employer is expecting bugs fixed and features added?
Yes, by myself. The client so far has been understanding... they've already burnt through several contracting companies, and I think they're starting to understand what a mess it is. But still, they want to see serious progress within a month (eg. large number of bug fixes).
I've turned around a few failing projects and rarely is the problem technical, most of the issues start with poor management.
Run away from this. Trying work with this code would make you stressed and frustrated, which will have a significant negative impact on your productivity.
If the company plans to add features to this software, they should hire more than one developers and perhaps rewrite it from scratch.
Edit: Also send your boss link to this discussion :)