Fortunately we had some empirical data to test this on as we had access to the code base for the project he was running. He had TDD going through out the system and although there were "minor" coverage issues in terms of branches the unit tests were all green and there were lots of them so everything was fine.
find . -name *Test.java -exec grep -A 4 catch {} \;
Ohhh dear the look on his face, very entertaining, the screen began to fill up with statements that looked a lot like this
catch(Exception e){
System.out.println("Test failed");
}
Yes folks a number (4) of his developers didn't have a scooby-doo how to write a decent unit test or how to write decent code and were just "going for green" by trapping the exceptions. The point is that the poor chap had been so used to having a good quality team that he had naively assumed that things that had helped graduates from top line universities improve would also help muppets improve. The problem was that the muppets pair programmed with the other muppets and no-one else in his remote team would pair with the muppets so the four of them ended up regularly changing partners but within a very small, and in bred, gene pool.
The point of this is that there are very few things that automatically find muppets for you and getting them to write more code to check their own code isn't one of them. You still should be doing things like code reviews and you should always be looking out for System.out if you are doing Java.
Anyway he has caught the issue early enough, extended the build to have some more checks and has instituted a weekly code review hour where two developers a week will have to present their code for critique and improvement.
Technorati Tags: Java
6 comments:
Well, that put a smile on my face...I had the word "Muppet" on the tip of my tongue as I read the subject in the blog reader. I needn't have bothered formulating a response!
Couldn't agree more.
unit testing by itself isn't going to unmuppetize your average graduate developer, but getting them into the habit of writing unit tests and reviewing the quality of the unit tests using code reviews, together qith good quality mentoring should in the end achieve the desired result
A serious proponent of "Agile Development" would not subscribe to the concept of any single technique delivering good code. Obviously unit testing on its own is not a silver bullet.
If somebody else is not verifying the test or providing some other form of verication (e.g. pair programming, code reviews) then bugs will obviously ensue.
Cheers, APC
Being clear, the project in question used two things to improve quality. Unit Testing and Pair Programming. But due to the social nature of projects the pair programming became muppet with muppet and thus bad practice became emphasised not reduced.
So they did use pair programming and unit testing... and the code was still crap.
While they were doing both pair programming and unit testing they were doing neither well.
One of the advantages of PP done properly is that the habits/skills of experienced/good developers should rub off on the less experienced developers. PP done properly would require mixing that gene pool up a bit.
Having said that, I do agree with your premise that muppet developers will produce muppet code and muppet unit tests.
OTOH maybe the muppets will create something that is more testable if they use TDD.
I don't agree at all. Because I think that the post title should be: "Why Unit Tests don't help with crap project leaders".
This project has already some problems:
- As project leader you should know the skills of your people
- If you have a junior developer or a developer that doesn't known about xUnit, you should give them some training.
- There is a big communication problem in the team: If I'm new to the team and I don't known how to do something, I ask. Maybe those developers asked and anyone answered.
Post a Comment