Code Review - How to miss the point...

Sometimes your arguments just don't weitght enough in the balance... 

I had the opportunity to "attempt" to contribute to Esther Schindler's article on Code Review.  She reached out on LinkedIn and I offerred help.  Now that I am reading her article I have many dissapointments.  Mostly related to not being able to make my contributions useful. 

Right from the get go I warned her about "meeting driven" code reviews.  These code review sessions where people each bring a tree's worth of paper and then beat the s**t out of the code worked on for a month.   They generally also spend a day reading a massive and scary amount of code before the meeting, a very costly process needless to say with limited output in general (at least from my experiences 10 yrs ago at Bell Northern Research and later at Nortel).

I could see from the other contributions she was provided with that this was the route she was about to embark when talking about code reviews.   Her article is filled with reference to "weekly review meeting"... or "meeting driven" code reviews. 

A couple good take aways are:

1. Jason Cohen from Smart Bear who is talking about a code review style that makes more sense, closer to what we believe in at Macadamian. 
   
2. Someone from Google who's is suggesting to do design review before you even consider doing code review. 

If I had to write that article I would put emphasis on what has helped us here to improve quality:

1. Small and frequent code review.  Get code reviewed on a daily basis.   This ensure you catch errors as soon as possible. 
2. Do design patch review - Just In Time Design - JITD (expression first heard from the mouth of Francis Baudet's sometime in the summer of 2008... ;-) )  This process, not only ensure that the first line of code will be a valid one, but also ensure that the deveopper starting the work took a step back and thought about the code to be written before to start writting it. 
3. Tools stack.  Do not neglect the use of proper tools to do the job, emailing a patch to each other works, but now a day there are very good tools out there.   

Last but not least, for code review to be effective you need:

1. this process to be part of your culture,
2. to foster an egoless programing environment, ensure understanding of the "what's in it for me" for your developpers,
3. to not only rely on this process to ensure quality.     

First and foremost, you need to not do code review once a weeek but have this process part of your complete breakfast.

Innovation through UX

This blog post by Jen has attracted my attention... I will probably state the obvious the same way Matt is good at doing (so he claims)... ;-)

Jen's post makes it obvious to me that the UX phase in a project might very well be the "easy" way to innovate in a project.  By comparison to a project without UX.  Here is why. 

First, software engineering people are mostly concerned about construction of the software.  Their focus is delivering the code.   

Second, software engineering people are... software people., this is their expertise. Many of these guys will be concerned by usability or innovation but this is not their primary focus.  They are first and foremost experts at software technology, tools, languages, software design patterns, mostly software creation centric stuff... (I believe for most of them at least)

Our UX team is by contrast much more in touch with the research world, it seems to be a natural aspect of their role to be aware of what is out there so they can integrate these academic projects into a real projects. 

In the example brought up by Jen it is clear that a software engineer could have thought of the multi-vibration thing but probably without awareness of the research project done in a particular university.  It would probably be a "wouldn't it be cool" kind of enlightment.  

As valid as this "wouldn't it be cool" idea might be it would lack the link to the academic research and would probably be much harder to sell if at all possible.

 

    

Tasks in Gmail!

Finally!  This is a premature post because since I have not played with it very much yet but in case you did not notice that it was added recently, now you know!

The one sad thing is I have not found a way to import from RTM... That's going to be annoying... Hang on... Google API... Mmm nothing there yet... 

This is to my knowledge one of the key feature that was missing to the "Google way" to email...