Rapid Development using Graduates whilst maintaining code quality
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 refatoring 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.
no comments yet.
Using GPL code within proprietory code »« Why Apple won’t make running Windows apps too easy
