I’ll See Your Two Heads And Will Raise You Seven
| Posted on Friday, October 24, 2008 |
0
commentsAdd comments |
One of the issues with the development of great code is the limited perspective of its developers. Not every programmer knows the ins and outs of a language, is able to harness every nuance of the language, or realized the ultimate potential (or weaknesses residing within) the code they have written. This is where peer reviews, hopefully, strengthen a project.
An old axiom says “two heads are better than one,” which definitely allowed my partner and I for the DueDates-Silver project to accomplish a very nice implementation. In my blog last week, I discussed how we used a carpenter’s approach of ‘measure twice, cut once’ in our design process.
If two heads are great, then nine heads would surely trump that old axiom. That’s what happened this week. Two weeks ago, my software engineering peers and I were split up into nine teams each working on their implementation of the DueDates project. This week, each team member was asked to review three peer projects and provide constructive feedback to that team of developers. This provided each project group the opportunity to see six implementations of DueDates, in addition to their design. Most projects were reviewed by six peers, while DueDates-Silver was lucky enough to have seven peers reviewing it.
Meting Assignments
Which projects to be reviewed and who would be reviewing them was predetermined by our professor, what capacity each reviewer would be asked to perform within the project review was determined by the project owners.
My review assignments were:
Those assigned to review DueDates-Silver were:
The documentation, classes, and design reviews assigned to each reviewer for the DueDates-Silver project were:
• Documentation – Anthony Du, Jung Jeho
• DueDates.java, UserLibraryInfo.java – Phillip Lau, Aric West
• Library.java, User.java, Book.java - John Zhou
• Testing Suite – John Ancheta
• General Conceptualization/Implementation Structure – Scheller Sanchez
Meeting Assignments
I really enjoyed reviewing the DueDates implementations created by my peers. Many of them had great ideas. For example, Anthony Du had created an ErrorLogger class that parsed the command line arguments that I thought would be very useful in future iterations of our DueDates-Silver project. Other projects did various forms of testing that were interesting, and seeing uses of Java API elements that I was not familiar with was enlightening as well.
Additionally, the comments gained from our reviewers will definitely strengthen the design of DueDates-Silver in version 2.0. For the most part, the recommendations are in regards to minor improvements to the design, such as altering toString() method returns. Others were more beneficial, such as suggestions for improving our testing suite and using String.format() for output to the console window. And then there’s always the comments for improvements to the design that you already know need to be improved, perhaps, even scheduled for version 2.0, but still, someone just has to point it out!
An old axiom says “two heads are better than one,” which definitely allowed my partner and I for the DueDates-Silver project to accomplish a very nice implementation. In my blog last week, I discussed how we used a carpenter’s approach of ‘measure twice, cut once’ in our design process.
If two heads are great, then nine heads would surely trump that old axiom. That’s what happened this week. Two weeks ago, my software engineering peers and I were split up into nine teams each working on their implementation of the DueDates project. This week, each team member was asked to review three peer projects and provide constructive feedback to that team of developers. This provided each project group the opportunity to see six implementations of DueDates, in addition to their design. Most projects were reviewed by six peers, while DueDates-Silver was lucky enough to have seven peers reviewing it.
Meting Assignments
Which projects to be reviewed and who would be reviewing them was predetermined by our professor, what capacity each reviewer would be asked to perform within the project review was determined by the project owners.
My review assignments were:
| Peer Project | Team Members |
|---|---|
| DueDates-Purple | John Ancheta, Daniel Arakaki, Mari-Lee Flestado |
| DueDates-Red | Phillip Lau, Creighton Okada |
| DueDates-Violet | Anthony Du, Vincent Leung |
Those assigned to review DueDates-Silver were:
| Review Completed | Peer Reviewer | DueDates Team |
|---|---|---|
| Yes | John Ancheta | DueDates-Purple |
| Yes | Anthony Du | DueDates-Violet |
| Yes | Jung Jeho | DueDates-Green |
| Yes | Phillip Lau | DueDates-Red |
| No | Scheller Sanchez | DueDates-Gold |
| Yes | Aric West | DueDates-Orange |
| Yes | John Zhou | DueDates-Yellow |
The documentation, classes, and design reviews assigned to each reviewer for the DueDates-Silver project were:
• Documentation – Anthony Du, Jung Jeho
• DueDates.java, UserLibraryInfo.java – Phillip Lau, Aric West
• Library.java, User.java, Book.java - John Zhou
• Testing Suite – John Ancheta
• General Conceptualization/Implementation Structure – Scheller Sanchez
Meeting Assignments
I really enjoyed reviewing the DueDates implementations created by my peers. Many of them had great ideas. For example, Anthony Du had created an ErrorLogger class that parsed the command line arguments that I thought would be very useful in future iterations of our DueDates-Silver project. Other projects did various forms of testing that were interesting, and seeing uses of Java API elements that I was not familiar with was enlightening as well.
Additionally, the comments gained from our reviewers will definitely strengthen the design of DueDates-Silver in version 2.0. For the most part, the recommendations are in regards to minor improvements to the design, such as altering toString() method returns. Others were more beneficial, such as suggestions for improving our testing suite and using String.format() for output to the console window. And then there’s always the comments for improvements to the design that you already know need to be improved, perhaps, even scheduled for version 2.0, but still, someone just has to point it out!
