Two heads are better than One: Peer programming

Working on a project with another programmer sitting right beside me was not a new experience. I originally started programming at a computer lab, where there was a large amount of people using a computer and every computer was placed next to each other in rows. So as I would program, my classmate would program on the computer next to mine. We were assigned to work individually, but when either one of us were stuck on a problem we would turn to each other for advice. This was my first encounter of peer programming.

Programming with another person, to me, is one of the most effective tools in programming. I had the honor to work with a classmate of mine, John Ancheta, in our ICS 413 class. Our task for the first half was to have the Emma quality assurance tool have 100% coverage on a pre-implemented Stack program. We both took turns implementing on my laptop, and it was good having another set of eyes watching what I did. After completing the first half of our in class work, we then planned on how to create bug, but yet maintaining the coverage of a 100%.

John had the idea of rewriting what a method returned when tested. We both carefully thought it through and saw that it worked as we hoped for. We wanted to see if we expected the toString method located in the Stack class would return the list of elements, when rewritten to “this.element.size()” instead of “this.element”. (Note disregard the quotation marks.) As predicted, the coverage of the program was 100%, but failed in our JUnit test of the new “toString” method.

After noticing how Emma can get a result of full coverage and JUnit can have errors. I see that this as a disadvantage, even though one had good results and the other bad results. From this experience though, the advantage was having another head to help think and share their knowledge; also to write proper test cases and what to expect.


Stack implementation