Pramatr Blog

Anyone that has been following @pramatrdev on Twitter will have seen the numerous tweets recently about Grails. I first started looking at Grails back in 2006? after a recommendation from a work collegue. It looked quite interesting and I managed to hack together something quite simple but it was a little hard work in places to get what I wanted out of it. It was early days for the project however and it looked very promising.

I’ve since recommended it several times to other people who were interested in building applications new applications. Most of the this feedback has been extremely positive so I’ve managed to get around to having another look at it recently. After @snaglepus suggested I check out Build twitter in Grails in 40 minutes (registration is required) I have to say I was very impressed. Since watching that I’ve gone from knowing absolutely nothing about Grails (three years it too long to keep information in memory) to building a sample application very quickly. After finding plugins for many of the tasks I wanted, I’ve implemented the logic I need and let the tool do the rest of the heavy lifting work which led to a very productive evening of coding.

I really love it when you find technology which just seems to work and does exactly what you expect it to do. There is still much I want to learn about Grails and I’m sure there are many other tips and tricks I can pick up along the way. At the minute I’m just looking through the many Grails books to find a winner and I think I have in The Definitive Guide to Grails, Second Edition. If you haven’t looked at Grails before, I really recommend you check it out and see what it can do for you. And if you aren’t following me on Twitter, I’m @pramatrdev and I’m sure there will be a few more tweets about Grails before the month is over .

After working in the technology industry for many years, I’ve had the pleasure of working with many avid gamers. Some of these are occasion players, but I’ve also worked with those that spent endless evenings and early mornings playing MMOs. The water cooler gaming banter is a regular occurrence; with discussions of last nights raid and the weekend guild meeting. It was therefore quite interesting when I started to read January’s edition of the gaming magazine edge which talked about hiring these same gamers.

“He replied that employers instruct him not to send them World of Warcraft players. He said there’s a belief that WOW player can’t give 100 per cent as their focus is elsewhere, their sleeping patterns aren’t great, etc. I mentioned that some people have written about MMOG leadership as a career positive, and he shook his head.”

After a little searching I found the original source of this quote and the proper context in which it was delivered. Although the opinion was that of a single recruiter and was merely a brief comment in a conversation, it seems to have generated a surprising amount of publicity (nearly 90k hits on the forum alone). Much of this was no doubt due to the telephone game nature of how this story was reported; in some reports it was a job interview, in others a huge employeer. The story had a life of it’s own and was reported in various incarnations, some widely inaccurate from the original. It did however touch a nerve and I was forwarded the same link several times from both gamers and none gamers.

It wasn’t so many months ago that I was reading about “the striking similarities between the skills required for online gaming and those required for real world leadership”. Jim Spohrer, Director of Services Research IBM said, “What we’ve found is that success as a business leader may depend on skills as a gamer”. Some people even went as far as to say that these games should be thought of as “a potential educational medium for complex social skills”. Others even contemplated resumes that include a line reading “level 60 tauren shaman in World of Warcraft.”

I have come across many hardcore MMO gamers who poses in-game qualities that any employer would jump at, but do these really translate into real world qualities? Are guild masters really project managers or lead developers in another guise? I’ve seen guild masters that organize every part of their weekend raid but I really wouldn’t be confident of letting them run the project schedule. Virtual world skills may help improve real world skills but I personally haven’t seen a correlation between the two. Guild masters may make great project managers but I wouldn’t personally use this status as an indication of potential ability.

Since reading the quote in the edge magazine, I’ve read more negative opinions about the impact these games have on individuals. Some anecdotal observations claim that playing these games is causing college drop-outs and led to people neglecting their studies. The results from a small poll even showed that 55% of people thought that MMO gaming affected their own school or work performance. The sample is small, but it’s still quite interesting that the very people playing the game claim it affects their own performance. Many follow up comments from the original story come to a similar conclusion; playing games makes you a less effective employee. But is that really true?

Balance and separation seem to be the dominating factors. Those gamers that I’ve really enjoyed working with were able to leave their gaming lifestyle at home, it’s something they do in an evening but it doesn’t take over their life. Those that really cause headaches think nothing of discussing group tactics and tech tree analysis during work, with the lunchtime forum reading quite easily turning into an afternoons reading. Morning naps are a common occurrence to make up for lost sleep when they were too busy the night before slaying the latest boss. But is this really any different to any other evening activity?

Everyone spends their spare time in different ways, but if that spare time activity starts affecting work on a regular basis, an employeer is completely justified to be unhappy about this. It doesn’t have to be a late night playing games, it could quite easily be a late night at the local pub or 4am coding on your own pet project. It doesn’t matter if last night you were a Death Knight, a Shaman a Warlock or just out partying, if you come to work an absolute wreck and the rest of the team have to make up for it, that’s just not on. When hiring staff, level 70s need not apply?

Over time I’m frequently restructuring and refactoring the code I work on to improve the design and simplify many of the balls of mud I find along the way. If I break some of that code my unit tests shout at me and if they don’t my continuous integration environment shouts at me when I’ve broken one of the integration tests. One area of the code that doesn’t receive the same attention however is the documentation.

I love a well documented API as much as the next developer. I also am fighting a constant battle to improve my JavaDoc skills, trying to write to the same quality that I see in many other projects. But is excellent documentation really enough? It can’t just be excellent when it’s written it needs to be constantly maintained to this same level over time.

It’s a pretty common occurrence that I can look at a section of code and find documentation that has nothing to do with the method it belongs to. The intention revealing name sounds nothing like the documentation which describes what it’s supposed to be doing. Somewhere in the mists of time, the intention of the method and the documentation parted company; it is documentation no more it is ex-documentation. The problem here however is that there’s nothing to catch this issue. If an extra argument is added, Eclipse might display a warning telling me it’s missing from the documentation, but the actual context of the documentation can be completely wrong and I am none the wiser.

Although this incorrect documentation may seem fairly harmless to some, the reason it was supposed to be there in the first place is to the give the user of the API information on the method contract and the expected outcomes. If this information is completely wrong however it introduces confusion and also potential misuse of the API. After much wasted time and several grey hairs later I recently filed a couple of JIRA reports about popular open source frameworks which did exactly this. After my code just didn’t work and the unit tests failed, it took me a number of minutes to realise that the JavaDoc description of expected events just didn’t reflect what was actually going on in the code.

One approach to solving this problem is to include the documentation in the frequent code reviews. Code that doesn’t have documentation or has incorrect documentation can’t be considered complete, thus doesn’t pass the review. Developers need to make sure however, that they treat the documentation with the same respect that they give to their code and their tests. When dealing with documentation I’d much sooner see a method with no documentation than something that is completely wrong. I do want a good level of documentation in the code I work on but there is a very simple rule; update it or lose it.

Reviews are a widely used technique to analyse code for the presence of defects and potential improvements. Many successful teams continually review code to try to ensure a high level of quality and to constantly improve a developers ability to write good code. The arguments for and against code reviews have been made on many occasions, but one common unknown factor for many teams is the frequency at which they should take place.

Infrequent Reviews

Many teams operate on a feature complete code review. At the end of the cycle of work, several developers sit down together with the author critiquing the delivered work. What often transpires here is that due to the huge mass of code delivered, the chances of a thorough review are rendered utterly impossible. The plethora of code makes it difficult to find a starting point and thus potentially problematic code isn’t allocated the time it necessarily deserves. Any potential recommendations that come out of this kind of code may never see the light of day given the pressing work schedule (if the code was complete why are the changes necessary?). Most importantly for the team, reviewing code so infrequently can lead to demoralisation of its members.

Code reviews may pick apart the authors code; code that they have potentially sweat and cried over (ok maybe not) and worked hard to complete. Does it really make sense to save up all the potential criticism and deliver it in one skull crushing blow? Even if the criticism is perfectly valid, nobody likes to feel good about something only for it to be completely torn apart. Developers complain when customers only let them know what they actually want when they see what they don’t, is the same really acceptable for the code? If infrequent code reviews aren’t the answer, how often can code be successfully reviewed?

Email Reviews

Some teams never let the author of the code commit it to the repository. Instead, they email the code (typically in patch form) to the code owner or one of the principal reviewers. The idea behind this approach is the patches are always reviewed prior to them being committed, and the developers can work productively only focusing on the task in hand. This process has the ability to ensure that every change is scrutinised and verified to maintain the high quality standards that are set down. Having had to work with a system like this in the past, I can honestly say that it was fraught with problems and was one of the most frustrating I’ve ever worked with (I was one of the principal reviewers).

The person applying the patch quickly becomes a bottleneck in the process, how long can people really wait for the patch to be applied? What should the patch reviewer actually do with the patch, make the recommendations themselves or send an email back to the original author to apply the required changes. If multiple people are working on the code base, the chances of conflicts increase. If the patches are applied in the wrong order or peoples timing is just plain unlucky, the person applying the patch has a multitude of problems to deal with. The version control system is full of only one persons name, thus making it incredibly difficult to track down the original owner of the change. Lastly should the worst happen and the build fail………………….. guess who’s change it was that broke it?

Frequent Reviews

People like to know what and how they are doing with their work. If infrequent code reviews lead to a big bang delivery approach, then frequent code reviews take the inverse approach of small nudges in the right direction. By applying these frequent reviews, developers can deal with smaller suggestions and recommendations early in their development. Instead of developers feeling they have completed something only to be told it’s all wrong, they can be guided along the process to ensure they arrive at a right answer. The most difficult question here is; how frequent is frequent? This is a very developer specific metric.

Some developers require frequent attention and when I say frequent I mean every few hours (or more!). As developers become more experienced, this frequency typically reduces until the reviewed eventually becomes the reviewer. Depending on the type of project however, it’s still quite common for very experienced developers to like frequent code reviews. If frequent reviews become very frequent reviews, you might have unwittingly found yourself participating in quasi pair programming.

Pair Programming

Pair programming is not only a great way to develop but also to implicitly review code. A second developer sitting at the keyboard provides instantaneous reviewing of code. The second developer not only reviews the code, but also looks for potential problems and improvements to the evolving code. The second developer isn’t always necessarily the reviewer, and roles can switch between either developer during the exercise.

Having someone take over the keyboard encourages the development to be of higher quality and a second set of eyes prompts the coders to produce good code (obviously given a good pairing of developers). This instant review and feedback can actually reduce the number of bugs introduced into the system. As several developers produced the code, it also means that the team is never reliant on a single developer to address a given area of code. Pair programming is an excellent way of developing an reviewing code, but it’s not without it’s problems with some people finding the feedback is just too often.

Summary

By reducing the time between code reviews, teams can provide better guidance about the eventual quality of code and prevent storing up potential problems. The less frequent the code reviews are the more problems (especially with less experienced staff) that occur. Developers want to feel like that are doing a good job and as such then need small bits of constructive criticism often instead of lots of criticism delivered all at once. Reviewing code is best addressed frequently, providing quicker feedback, and reducing the amount of rework involved. As a developers ability increases, these issues typically subside and they become active in reviewing other peoples code.

If infrequent code reviews are problematic, are frequent code reviews the key to success?

I recently stumbled across a new site called RefactorMyCode.com. The strapline reads:

“Have you got a method that you’re dying to simplify? A class that’s growing out of control? Or an algorithm that you just can’t get working? Submit it to the new, awesome web app Refactor My Code, and have it refactored.”

RefactorMyCode.com

That doesn’t all sound like refactoring, but I’m always interested in new resources so I thought I’d have a look.
Read the rest of this entry »