Outrospective.org

In my experience, there is always one family that always gives the good Christmas and birthday presents, the ones that you remember into your adulthood.

For me, that family was my mum’s brothers family, and apart from their enormous generosity they showed our family, there are two things that came from them that I can say had some influence on my development as a computer geek. The last one was an Amiga computer which just helped me stay in touch with the rest of the computing world whilst everything had moved onto PC’s and the regurgitation of Windows 95 and this new ‘multimedia’ buzzword that these PC’s could do. Pfft.

Anyhow, the other gift, was a huge Lego set when I was about 3 years old. As you know Lego is modular, each piece does its specified task, and if you ever had to unit test a Lego block, it’d have well defined behaviors to make this a straight forward task (we’d hope).

Now when you start considering the connections Lego pieces can have with each other, there are a number of permutations possible. Lego’s are blocks that form structures in our space and have to live by the rules of gravity and laws of ‘building strength’. We can shape (and even force) these structures to take somewhat unusual shapes that challenge the contract that each lego block has with its neighbours by trying to squeeze the sides of piece into itself (to allow a triangle or odd shape piece to fit). Or we can challenge the laws of gravity by arranging the pieces one on top of the other until the slight variations in each piece cause the stack to start arching over to one side and eventually fall.

Such problems are unforeseen during the design of the Lego piece. Where do we go from here? Do we enhance our existing Lego block with new means to cope with these conditions? Such as a fan to keep the piece in an orientation when the promiscuous falling condition is met, or a removable lego side to allow for those hard to fit pieces to overlap somewhat.

http://www.niallkennedy.com/blog/archives/2006/11/google-mondrian.html

Recently at my work, someone asked, why do we keep lacking unit tests? Now there are many varied reasons for this and the discussion can go on forever, but I should say, that there is an understanding amongst us that unit tests as well as other tests (ie user acceptance) needs to be done after an item is completed.

The problem as I see it, is the lack of review at the end of the completion of the item. If we do not review each others work, not just the code, but the process, the checks have been followed, verify the user has reviewed and is happy with the work, verify the work against the user spec, SUFFICIENT TESTS EXIST, etc, then we cannot ensure quality.

We are a small team, there is no assigned quality manager who is responsible for the above quality controls being followed.

The point of this blog then, is to introduce a tool Google wrote for themselves, they name Mondrian. It’s purpose is to do web based code reviews. Ok, so my intro above was a little disjointed to the subject, but it does reduce the barriers in doing code reviews, in my opinion, what should be a strong quality control feature. It provides an audit trail of these said features also.

Look at the attached video of the presentation of Mondrian. The first 15 mins serve as a great introduction into the problems of code review (emails flying around, finding someone to do the review). I like that the presenter makes the distinction: Some places do pair programming, others do code reviews. Both are in XP, but it seems that one or the other are both strong quality controls and in a place where there aren’t the staff to devote to pair programming, increasing the importance of code reviews sounds like a pretty sound manoeuvre.

http://eureka3d.com/blog/?p=21

Do you find yourself constantly checking for null

Does your clever little method now look like a small mess after you’ve incorporated your null checks? Do you find yourself asking, ‘how is anyone else going to ever follow that now’?

If so, then how is this for a neat idea? Write a language with a keyword that tells the compiler that a parameter you are passing or expecting to receive from a method cannot be null, and as a result of this checking, know that you can code the method with a lot more clarity and an immunity to null pointer exceptions.

Steve Riley’s 2 part blog on this subject poses the above scenario and some solutions even for those of us stuck in a language we cannot neuter the nulls. It’s a very enjoyable read.