Agile Austin - Peer Code Review – An Agile Process

At last night's Agile Austin meeting, Gregg Sporar gave an excellent talk on Peer Code Reviews to seventy attendees. Here are a few of my cryptic notes:

1. Professional writers have editors, why shouldn't coders? In fact, in the US we are blessed with twice as many professional editors as writers.
   
2. We need to move the feedback closer to origin when writing code. The earlier the code is peer reviewed the better. Should code be reviewed before being checked-in?
   
3. One of our Agile principles is Collective Code Ownership. Peer reviews aids this process by helping everyone understand the code.
   
4. If coders know their code will be reviewed they code better.
   
5. Peer reviews help everyone learn new techniques for programming.
   
6. Michael Fagan, the founding father of code reviews encouraged lots of meetings. Is roi there for lots of meetings? Only 4% of bugs are found in meetings.
   
7. Types of Code Reviews:
   
   
   
   1. Over the shoulder code review. Just grab a friend and have them look over your shoulder at your code.
      
   2. email
      
   3. pair programming
      
   4. Automated tools
      
   
   
8. How long to review code. Studies show most bugs found in 60-90 minutes. On average 1 bug per 10 min.
   
9. How many lines of code to review? 200 loc per hour seems to be the sweet spot.
   
10. Regarding checklists: Don't put too many items in a checklist. 5-9. Error handling would be a good item for a checklist.
    
11. One way to review code is to only review unit tests to make sure they are thorough, and then the code should be fine.
    
12. A few suggestions for not letting the reviews get to heated: Remember it's the tone that counts. Also "Ask don't tell", (e.g., Why did you use this API?)
    
13. Smartbear offers a free book at Codereviewbook.com
    
14. Gregg blogs at Blog.smartbear.com.
    

Embedding date and time into a file in windows - "But it worked last night"

I'm patching a tiny project at work with duct tape until we can get an enterprise solution. A small batch job runs on the windows scheduler doing something like this:

MyCommand.exe  --output=Saturday1201amUS_%date:~10,4%-%date:~4,2%-%date:~7,2%-%time:~0,2%-%time:~3,2%-%time:~6,5%.txt

I ran it yesterday afternoon and it worked great. It created a file named
Saturday1201amUS_2009-12-21-15-46-00.21.log. This morning I did another test with my client and it failed miserably after creating a file named 'Saturday1201amUS_2009-12-22-'. A little investigation turned up that windows does not prepend a zero in front of the hours before noon so my executable file was getting a space in front of 9 oclock:

MyCommand.exe  --output=Saturday1201amUS_Saturday1201amUS_2009-12-22- 9-47-20.31.log

It worked great after putting quotes around the file name.

MyCommand.exe  --output="Saturday1201amUS_%date:~10,4%-%date:~4,2%-%date:~7,2%-%time:~0,2%-%time:~3,2%-%time:~6,5%.txt"

One Stock Trading Company Claims Compute Power of Lawrence Livermore

Interesting article from Technology Review about the computing power of the high-speed stock traders:
The explosion in high-speed automated trading has engendered a massive buildup in technology; Renaissance Technologies, a hedge fund based in East Setauket, NY, boasts that its computing power is equal to that of the Lawrence Livermore National Laboratory.

NHibernate Intellisense for Visual Studio 2008

From the NHibernate distribution, I renamed nhibernate-mapping.xsd to nhibernate-mapping-2.2.xsd and nhibernate-configuration.xsd to nhibernate-configuration-2.2.xsd. Then I copied those two files to C:\Program Files\Microsoft Visual Studio 9.0\Xml\Schemas and immediately intellisense started working for me in Visual Studio 2008.

Bitter Refactoring

Kimberley Bitter
Originally uploaded by kamoda

After reading Martin Fowler's book on Refactoring I've been a big fan of the practice. We all know that adding in tests to insure the refactoring doesn't change the results is essential.
But this last week the real world crept into our world of programming paradigms. We refactored a complicated section of code to make it simpler, more readable, and faster - a big win; except that after the code was fielding, one of our customers reported a problem.
Their use of our product actually depended on a bug in the old version. Refactoring the code fixed the bug and caused our customers grief.
I'm still a big fan of refactoring and continue to do it, but now I'm a little wiser that refactoring carries more risk than I'd thought before.

Simian - a code duplication finder

Today I downloaded simian, a code duplication detector. It's very easy to download and run. Simian detected a few chunks of duplicated code, which need to be refactored into a single method, or pushed up into a parent object. Simian is worth a quick download to test your code. Eval copy is available for free.

C:\opt\simian\bin\simian-2.2.24.exe -reportDuplicateText -threshold=5 *.cs > simian.txt

Agile Austin - Domain Driven Design and the Naked Objects Pattern

Last night at Agile Austin Eitan Suez explored the relationship of Domain Driven Design and the Naked Objects Architectural pattern to a packed house of 60 people.
The thing that struck me the most was how using the Naked Objects concept of having the objects themselves create the GUI forces a Ubiquitous Language on the developer since the user will see the object and method names on the screen.
Eitan gave a great example by having the jMatter framework autogenerates a permissions table with objects and their actions on the vertical axis and the types of users on the horizontal axis by reflecting the code and dynamically discovering the objects, their methods, and the types of users.