How to organize the work when project needs to be re-implemented due to poor code quality?

Question

Hi,

I have been asked to join a very small team where one main developer has been buiding the web app (.NET 4.0) during ~6 months. The project should be delivered within next 2 months.

After first look at the code I can say that I would never allow it to go to production (things like catch { }, no tests at all with WebForms etc).

So the code quality is incredibly low.

My task is to improve that and still deliver the solution. So I plan to start with unit testing and MVC2 reimplementing most of the functionality (though using some of the existing code).

I estimate that I will need about 6 weeks to catch up with the current progress and be on te same functionality level as the application will be in 6 weeks.

The problem is that the main developer who has been working on the project seems to be really starting in IT and many basic things are unknown to him. It will take significant amount of time and effort to educate him how to do the proper testing, development and apply some patterns.

I am ready to take responsibility for the reimplemnting the application but at the same time I don't want the main developer to be on idle but as he won't be able to significantly contribute to the better-world project at this stage I am not sure what would the best way to keep productivity high for both of us.

Currently I think following solution is good enough: He proceeds doing what he does until I will catch up with him and then start working on a new project together.

The problem is that of course this approach is not very productive as one developer will do better-world project while the other will proceed with what he did, effectively doing similar tasks.

Another approach would be to pair and try to do things together, but again not sure how productive we will be.

Can you suggest how we could better organise the work together in order to be most efficient for the overall project?

Thanks,
Dmitriy.

Answer 1

I would first suggest get to 1.0. Forget the code quality in the initial release. It is really trivial to the end game of delivering the product.

THEN take the lead and setup proper branching processes to properly review your coworkers code BEFORE it hits the build.

Finally, if all else fails not everybody is cut out to be a programmer and this may be your coworker.

For a decent programmer we see code quality as a critical factor in an application, and in some cases it is. However in most cases we aren't going to get much added performance by doing it right. So I'd shoot for a badly written 1.0 and then fix it.

Answer 2

1) As Clarence mentioned, first ensure that you REALLY need this rewrite. If you don't need it by that deadline, fix it later. If not:

2) Tell him what you want. Point him to examples of code that are of the quality you desire.

3) Point out in this example code the key elements that make it the high-quality code you are looking for.

4) Give him a coding guideline that re-emphasizes point 1 and 2.

5) Proceed with your original plan, but try and limit his portions to small algorithms that you can drop into place or portions small enough for you to easily refactor. If possible, write up the important functions yourself and just have him figure out how to call them in the right order, or outline the work for him so it's a matter of just turning pseudocode/fine-grained directions into code.

Answer 3

I think you should make a priority list:

• what can we absolutely not ship with (security risks)
• what can we ship with, but should patch later (buggy areas)
• what can we ship with, but shouldn't repeat in the future (bad structure/practice)

1- Fix the first items, only.

2- Ship the product.

3- Fix the second list.

4- Educate coworker, or release