If the code is in a bad situation, it will need to be refactored. There's no easy way around that problem and pressing on the pedal harder will not solve it. What you'll need is three things: a features list, a test plan and refactoring / testing skills.
The feature list would contain all of the features that the current software provides. Have the engineers / product team build up this list and agree upon it because it will become the standard for what features are in the software.
Next, for each item on the feature list, you want a test to verify that each feature is present and working in the software. For now, this list can live as a word document, describes the feature at a high level and provides instructions to the engineers / product teams on how to test this feature. Later on, this might exist as a set of programming tests that the engineers write as they go along.
For an ecommerce site, one of the most important features is the search functionality. So an example of this could be:
1. Search box returns product suggestions based on the user's input:
* User types: Acrylic Sign Holder
* We expect acrylic sign holder products to appear on the search results page.
This is clear enough for both the engineers and product teams to know what is expected of the software.
You will take the feature list and test plan, and go through them to make sure those features are in place. This will prove that the product being built matches the agreed upon specification.
If the code is in a bad spot, you will need to refactor it. Imagine that there is a giant pillar in your house that is supporting the roof. Terrible design. However, you want to turn that area into a kitchen. What would you have to do? It's going to suck, but you have to add additional support in the right places to support the roof and then remove the pillar. That is essentially what is happening in the code.
Now, if I was handed a block of messy code, but I had the features list and test plan, then I would have at least some confidence in cleaning the code, since I could vaguely separate what is incidental code (part of the framework / infrastructure) vs what is relevant code (part of a feature).
So for your questions:
How likely is it for a new dev team to come to a project and refactor the code ?
If so, what would you need to be able to pull it up without getting crazy ?
If the code is bad, then it must be refactored in some form to remove the blocking points that are prevent us from completing features. Is it possible to refactor the code while delivering a new feature? This would help identify the "pillars" and then we'd refactor / clean the code that we are working on or needs to be done. Otherwise, engineers might refactor things that may need refactoring, but could be done at a later time.
If so, what would you need to be able to pull it up without getting crazy ?
From above, refactoring for what feature comes next and any pillars stopping us from completing the feature will keep refactoring down to the necessary minimum. I would not patrol and enforce what the engineers choose to refactor, since they are essentially the ones that have the knowledge to make that call.
To make matter worse, the project manager took decisions based on his misunderstanding of the design, implemented the wrong thing without advising and we have been in a debugging mode for months. The more we solve, the more bugs comes.
Maybe the feature and test plans can clear up the confusion on what need to be delivered and create a shared model of what is to be done. The end goal is to create that shared vision.
I am looking for options, but in my understanding it would be worse for a new team to come and clean the mess as even the internal team of the agency are insecure about their own code.
The old team understands the code-problems and what is being delivered. I would vote to keep them in place and have them work on new features while refactoring the code. Progress will be slow, but it should ramp up as the code becomes cleaner.
Of course, this is from my view as an engineer and hopefully someone who has more experience in managing projects can chime in here. Hopefully this helps a little bit or at least gives you some fresh ideas on the situation at hand. ^^
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If the code is in a bad situation, it will need to be refactored. There's no easy way around that problem and pressing on the pedal harder will not solve it. What you'll need is three things: a features list, a test plan and refactoring / testing skills.
The feature list would contain all of the features that the current software provides. Have the engineers / product team build up this list and agree upon it because it will become the standard for what features are in the software.
Next, for each item on the feature list, you want a test to verify that each feature is present and working in the software. For now, this list can live as a word document, describes the feature at a high level and provides instructions to the engineers / product teams on how to test this feature. Later on, this might exist as a set of programming tests that the engineers write as they go along.
For an ecommerce site, one of the most important features is the search functionality. So an example of this could be:
This is clear enough for both the engineers and product teams to know what is expected of the software.
You will take the feature list and test plan, and go through them to make sure those features are in place. This will prove that the product being built matches the agreed upon specification.
If the code is in a bad spot, you will need to refactor it. Imagine that there is a giant pillar in your house that is supporting the roof. Terrible design. However, you want to turn that area into a kitchen. What would you have to do? It's going to suck, but you have to add additional support in the right places to support the roof and then remove the pillar. That is essentially what is happening in the code.
Now, if I was handed a block of messy code, but I had the features list and test plan, then I would have at least some confidence in cleaning the code, since I could vaguely separate what is incidental code (part of the framework / infrastructure) vs what is relevant code (part of a feature).
So for your questions:
If the code is bad, then it must be refactored in some form to remove the blocking points that are prevent us from completing features. Is it possible to refactor the code while delivering a new feature? This would help identify the "pillars" and then we'd refactor / clean the code that we are working on or needs to be done. Otherwise, engineers might refactor things that may need refactoring, but could be done at a later time.
From above, refactoring for what feature comes next and any pillars stopping us from completing the feature will keep refactoring down to the necessary minimum. I would not patrol and enforce what the engineers choose to refactor, since they are essentially the ones that have the knowledge to make that call.
Maybe the feature and test plans can clear up the confusion on what need to be delivered and create a shared model of what is to be done. The end goal is to create that shared vision.
The old team understands the code-problems and what is being delivered. I would vote to keep them in place and have them work on new features while refactoring the code. Progress will be slow, but it should ramp up as the code becomes cleaner.
Of course, this is from my view as an engineer and hopefully someone who has more experience in managing projects can chime in here. Hopefully this helps a little bit or at least gives you some fresh ideas on the situation at hand. ^^