@author dantheman
Every project has its gremlins! My Current Project has been plagued with CVS quirks and all manner of niggles. Currently I’m working in house in Brighton doing Java Development for NetBenefit PLC on there domain Registration Requirements system with Stuart Johnson and Pete Mc Partlain and its good! My journey to work has never been easier (20 minutes on a bus rather than 2 hours in traffic) and getting home at a sensible time is great.
One of the gremlins that seems to come around again and again is the “big problem ” that is actually an accumulation of lots of smaller problems that we didn’t have time to fix earlier. One thing I think can ease this burden is making people have pride in there work and making them accountable for there code.
On the last project I was working on we had huge problems tracking down where poor code was originating from, my friend Meeraj posted an article on his java.net blog called “@author bob the builder” detailing what we did to ease this burden and help the offenders improve their code.
When I was working there was a great atmosphere amongst the team (a large team consisting of ~ 70 people !) and the whole project was a scream from start to finish, even the hours spent coding thru the night were good fun in hind sight even if they were a bit of a slog at the time.
The first thing we did was acquire a dedicated machine to run continuous integration builds on, installed Linux and CVS along with JCSC, PMD, CVSSTAT and tomcat. Pretty soon we had a continuous build process running that checked out the latest code from the HEAD branch of our CVS repository and ran all of our code metric tools to gauge the good the bad and the down right ugly code that was lurking in our CVS repository. The one thing that nearly stopped us in our tracks was the lack of @author tags in the code, and the ones that were there was the default entry from the individual developers IDE.
After a few days and a lot of nagging, we eventually had @author tags in all the code and we could start holding people accountable. We tweaked the metrics to match out the sun standard coding style and ‘Bob the brain’ came up with some rules with regards to good and bad practices. we developed a web interface for the build process so you could watch it happening from your web browser and after talking nicely to the facilities department we managed to get the projector in the room working and we projected the JSCS / PMD results on to the wall with the top 10 best and the top ten worst classes in the project along with the @author tag from that class.
People were now accountable for their code! - I should say at this point that all of this was in good fun and the whole affair was quite light hearted and no one was actually blamed for anything! On the whole this was a total success and the code for the project (all 1.3 million lines of it!) grew more and more stable by the day, if someone saw their name on the either the ‘Guru list’ or ‘Wall of Shame’ as they became known they would do their best to either brag about it or hurry up and fix the offending classes that put them in the bad guys list.
The other thing that happened was people started taking a lot more pride in their work, and despite having a team of very fatigued developers from all the hard work and long hours they had been putting in we had a very solid product delivered in an incredible amount of time.I think Meeraj summed the whole thing up nicely with the following:
“Code that is not owned encourages poor coding practices that lead to totally un-maintainable code and ultimately utter anarchy. This isn’t anything specific to our industry, whatever craft you do, it is extremely important to take pride in your work. It is important to let people know it is your piece of work. It is not about promoting finger pointing or blame culture. It is about having pride in your work. It is also a mark of responsibility. It is about taking ownership and having the motivation to produce better results.”