Recently I have been ironing out our in house development process, making sure we are using the best tech possible to get the job done to a higher standard and more quickly. One of the most interest things that I have come across is that code reviews spot on average around 60% of issues in code (that’s more than unit testing, acceptance testing, basically its more than anything else!) so top of my list was getting a code review process in place!

One of the most difficult things I have found is getting an effective code review process in place. In my previous company this was done as a combination of emails, excel spreadsheets and code checkouts - not exactly a process that is 100% reliable. The other negative about a process such as this is its very hidden, if one of my team was reviewing another persons code I would never see the review process happening (unless I was CC’d in on every email!). So I went looking for a better solution…

After a lot of searching and testing I found Review Board, an open source project that is developed to take a lot (not all) of the pain out of the code review process.

Review Board can be set up in a number of ways (something that i’d like to cover in the future) and to be honest, its a real pain to get it set up and working, something which the review board team are working on. Once you have it set up its great, inside it you can view diff’s of code, add comments to lines, mark entire parts of code as ready to ship and best of all its out in the open and public so the whole team can learn.

I’m pretty sure that if I just installed a tool and that was it then the process wouldn’t work so I came up with 5 golden rules of code reviewing for everyone to follow to ensure we get the best out of our great new system:

1. Its a code review, not a code flaming - all reviews should give praise as well as pointing out potential issues.
2. It’s just code - Reviewers are reviewing the code only, if you don’t like the person, the coding standards or even the project it doesn’t matter you are only there to review the code.
3. Standards are all important - Leading on from 2, if you don’t have a set of standards you cant expect reviews to be fair. So get a set of standards and everyone reviews against them (even if they don’t like them)
4. There are always options - no-one is right all the time, for any problem there will be at least 3 or more ways to solve it. So use the code review as a discussion of why they used method A over method B. It may not be the approach you would have taken but that’s part of being in a team.
5. Set your own standards high and live by them - Can you imagine someone that reviews every-one’s code saying its awful, it doesn’t work, etc, etc and then checks in code just as bad? Remember to be a part of the team, check in code that you would like to see checked in and then have an open discussion about it to make sure its as good as it can be.

Ok one bonus rule:

1. Coding is a team sport - Remember that to create a great piece of software takes a great team, not just one great programmer. Code reviews are a process where you can make sure the code that is being shipped is of suitable quality as a team, and you can ensure that every time you perform a code review the whole team is improving the standards of what they produce by learning.

The more and more I use review board, the better the code is getting and the better the team is getting so i’ve got to say a big thanks to the team at review board for creating such an awesome piece of software!

Possibly the best general java book to date has been release in a second edition!

Effective Java covers all areas of the java API and really improves you ability, I loved the first one so the second edition can only get better!

On order from amazon as we speak, i’ll review it when it gets here but i expect good things, pick up a copy as well if you want.

There’s also a presentation on it from the author Josh Bloch on youtube which makes me want the book even more (thank god for amazon prime!)

Chris

As a programmer, coder, developer, manager, etc your often asked (usually at the most inconvenient of times) how long will this take to do? It’s at this point you normally put your finger in the air, check the wind and make a guesstimate, unfortunately these guesstimates often have a habit of becoming exact deadlines. Well no more, I’ll show you a two easy ways to avoid this situation and improve your estimates.

Getting out of jail

The next time you get caught of guard to make an estimate, don’t! Avoid this situation at all costs. Although this sounds impossible its really not, here’s how its done…

In one sentence I just used 3 techniques - calling on previous experience (A), using the experience of others (B) and simple honesty (C). I also offered a perfectly reasonable solution in returning a better estimate later, no project is so rushed that you must make an estimate withing 10 seconds and if people try to force you just say “I don’t know, I need to research it” if you don’t know then how can they argue?

Getting your estimate more accurate

Ok you just bought yourself a few hours and you already have reasonable estimates for A and B, but how do you estimate C? You’ve never done it before so where do you start?

Lets pick an example: Writing and running hello world on an android emulator (just assume you’ve never coded android)

After a bit of looking around your going to find out you need to get an IDE, set it up with android, code it, run it. You think it will take 5 hours.

STOP!

Before you rush off with your first instinct lets look a little bit deeper using a 3 point estimate, for this we need to consider the best, expected and worst cases for the task.

Best: You install the IDE and android SDK, follow the guide online, click run and it works - 3 Hours

Expected: This is your gut instinct, that’s the one up above before I screamed stop! This is what you think it will be, not exactly halfway between best and worst. So for our case it will be 5 hours.

Worst: This is where you really have to think, what can go wrong, maybe the IDE can’t be installed, what if the SDK has an issue integrating well and you need to research why, what if the emulator doesn’t deploy properly on your OS. OK you could go on a lot here, probably way too much and sometimes you need to assume things so lets assume the IDE and SDK install as expected but it takes you longer to figure out the code, its only a simple bit of code so it means you take 9 hours in total. Worst case is now 9 hours.

The last step is to turn that into your estimate (math time).

The final thing you need to do is get a 3 point estimate for all of this, that’s pretty easy too its…

(Best + 4 Expected + Worst) / 6

So in our case its

(3 + 4 * 5 + 9) / 6

= 5.4 Hours

Although that may not seem much different, the more risk you have in a task the more it varies the resulting estimate. Using this method you can also monitor the risk attached to any task and compute how likely your estimate is, i.e. I will finish this task in 5.4 hours plus or minus 7% but that is for another day to explain!

Chris