Graduates heavily outnumber your senior developers? Get the graduates to get the code working; Get you senior developers to re-factor. Result? Rapid development of good quality code.

I've got a few years under my belt as a developer, and I like to think of myself as fairly competent. I reached that point where it pains me to see poorly written code; not only is it ugly, but I feel compelled to fix it.

I don't know when exactly I reached this point, but it has recently been brought to the fore-front of my consciousness, as this is the first time since then that I've worked with graduates; not just a few of them, a whole slather.

Now let's face it, graduates rarely know how to code well. Admittedly, the company I work for is fairly smart, so the graduates have to write unit tests and their code gets reviewed by a more senior developer; All good, but when it boils down to it, the code is still crap (hey, look at my graduate code and I'm sure you'll agree).

It pains me that the product we will be delivering will be full or crap code, so I thought about ways of solving the problem. The graduates outnumber the senior developers about 3 or 4 to 1. The graduates are great in that they keep the budget down and do actually produce code that works (when they are kept in check by the unit tests and reviews). The senior developers are good at coding, though they don't have much time to do any, because of other task assigned to them (architecture design, team leading, project planing, etc).

Looking at the problem again, I realized that getting the code to work (given a competent design) and writing unit tests is a grunt job; A suitable task for said graduates. Getting the code into a clean state requires a senior developer, but (fortunately) this takes considerably less time than actually getting the code to work.

From this point of view, it makes sense to me to create re-factoring tasks for the senior developers and to give them no other development tasks. The gruntsgraduates do the primary development and the senior developers clean it up.

With this approach the senior developers don't have to spend the little development time they have getting code working, instead they can focus on cleaning it up, extracting common functionality and ensuring that when the product is delivered, the code is in an extensible and maintainable state.

I've tried unsuccessfully to run it by my project manager (he's a great PM, but a very 'by the book' kind of guy) and he raised some valid points that I will attempt to refute:

• If there are problems with the code, then this should have been picked up during the code review, be raised with the developer, who is then responsible for fixing it.

  This assumes that the person (or people) doing the reviews have time (and the skill) to pick up all these issues, which is not always the case.

• If there are problems with the code that are discovered post review, then it should still be raised with the developer, who is then responsible for fixing it.

  This assumes that the senior developers have time outside of their other tasks to look at the code that the graduates are producing, which is not always the case.

• Code that is duplicated amongst modules developed independently should be part of a utility library, which should have been detailed during the design phase.

  This assumes that the designers had the time and knowledge to foresee this common functionality, which is not always the case. Often during development there are issues that only present themselves during the build phase, which were not even contemplated during design.

To resolve the issues above 'by the book', the senior developer must detail a solution, convey it to the graduate and then the graduate must implement it and then have it reviewed. This can IMO take just as long, if not longer than what it would take for the senior developer to simply make the changes themselves and have it reviewed.

I need to make it clear that I have not tested or experience this approach, so there may be significant pitfalls:

• Will the senior developers feel demoralised because they are always cleaning up crap code?
• Will the graduates feel demoralised because their code is constantly being overhauled by someone else?
• Will the graduates produce even worse code because they know someone else will clean it up?
• How do you facilitate the transfer of knowledge from the senior developers to the graduates, so that they too may one day be senior developers?

Despite the open questions, I feel it the approach has enough potential that is should be shared. I will continue to lobby my PM to give it a go, but if you try it, have tried it or have experienced it, please let me know how it goes/went.