Peer Code Review – An Agile Process
Location:Microsoft Technology Center; Stonebridge Plaza One; 9606 North Mopac, Suite 200, Austin TX, 78759
Peer code review can be one of the most effective ways to find defects – but is it Agile? Agile developers hate heavy process, and it's easy to waste time when code review is done poorly. However, lightweight peer code review aligns well with the central tenets of Agile including keeping feedback close to the point of creation, increasing team velocity by finding defects faster, and improving collective code ownership through frequent collaboration. Gregg Sporar shares some of the research on code review and describes best practices for an agile approach – how much time to spend, how much code to review at a time, the value of annotation, which code to review, how to set goals, and more. Gregg compares four common styles of review – over-the-shoulder, email, pair programming, and tool-assisted, and gives specific advice for building checklists and dealing with the social effects of code review in an agile environment.
Gregg Sporar has been a software developer for over twenty years, working on projects ranging from control software for a burglar alarm to 3D graphical user interfaces. His interests include development tools and processes, user interfaces, and performance profiling. Gregg has worked on teams that range from mostly Agile to hideously rigid and is currently Senior Product Manager at Smart Bear Software. He has published several articles, contributed to a couple of books, and has spoken at software developer conferences around the world, including Agile Development Practices, SD West, OSCON, FISL, JavaOne, Jazoon, and TheServerSide Symposium.
Cost: Free
Contact: www.AgileAustin.org or info@AgileAustin.org
Proof of Attendance forms will be provided for PMI (PDU), ASQ (RU) and NPDM (PDH) re-certifications


Comments
Wish I could attend, but
Wish I could attend, but this is opposite the Austin Amateur Radio Club meeting where there will be a presentation on Software Defined Radios.
I have been a major proponent of peer review for decades now. Many studies have shown that it is the single most effective way to reduce code defects. It's also something that is almost universally ignored. This is one of the major reasons I am no longer a software developer, too many teams lack the drive to produce truly high quality software, mainly because too many developers take it personally if someone happens to spot a bug in their code.