I'm blogging about programming, but ... hey look over there - it's something shiny!
Tuesday, January 19, 2010
Wiping Disks Clean with Free Software from dban.org
Recently I needed to wipe the hard drives of a few machines. I was very pleased with Darik's Boot and Nuke ("DBAN"), a free program from dban.org. Before you donate your old computer, or even put it out at the curb for trash pickup, be sure to wipe the drive clean; even erased Quicken data can be read from your old hard drives.
Wednesday, January 06, 2010
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:
- Professional writers have editors, why shouldn't coders? In fact, in the US we are blessed with twice as many professional editors as writers.
- 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?
- One of our Agile principles is Collective Code Ownership. Peer reviews aids this process by helping everyone understand the code.
- If coders know their code will be reviewed they code better.
- Peer reviews help everyone learn new techniques for programming.
- 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.
- Types of Code Reviews:
- Over the shoulder code review. Just grab a friend and have them look over your shoulder at your code.
- email
- pair programming
- Automated tools
- Over the shoulder code review. Just grab a friend and have them look over your shoulder at your code.
- How long to review code. Studies show most bugs found in 60-90 minutes. On average 1 bug per 10 min.
- How many lines of code to review? 200 loc per hour seems to be the sweet spot.
- Regarding checklists: Don't put too many items in a checklist. 5-9. Error handling would be a good item for a checklist.
- One way to review code is to only review unit tests to make sure they are thorough, and then the code should be fine.
- 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?)
- Smartbear offers a free book at Codereviewbook.com
- Gregg blogs at Blog.smartbear.com.
Subscribe to:
Posts (Atom)