Senior Seminar

Senior Seminar – eXtreme Programming Homework 3

Pair Programming Programming Practice Summary

Total Time	49	180	90	210	90	180	180	70	90	270	75
Design and Test Case Development Time	15	165	60	40	50	180	30	15	30	60	35
Coding percentage	40/60	40/60	27/25/30	60/40	35/65	60/40	20/50/30	30/55	90/10	70/30	35/60

Which did you like most? Coding or strategizing? Why?

Coding	Strategizing
because I like to be in control	not worry about the details and could just look for errors
we all talked about what was being coded all the time	requires more thought to develop a strategy
I could get my ideas across through typing	I liked focusing on the design
When not typing, I had to explain what was wrong	Partner could type faster
because it really helped to have an extra pair of eyes, and brain behind them, to watch for the little bugs that can be hard to spot.	coding what we already know is easy, it is the figuring out that is hard.
By coding we can check if the strategy is working or not	I preferred to think about the big picture, rather then the little details along the way.
I like to be in control when working on everything that i feel i can do well.	I like strategizing more. This makes me have a complete look toward the program
I would say coding if pressed, but I'd rather say both. Seeing the project coming together faster than it would have if I'd been working on it alone and unmotivated was more rewarding than playing either role.	Strategizing, because once it is established how to implement something the implementation becomes mundane.
I like coding because it keeps me awake during the project. I love to code	I like strategizing most because I believe that designing a good solution to a given problem is more important and more challenge than coding itself.
I actually preferred the coding because the plan took quite a while to think out and I was anxious to get into it.	Strategizing. My partner had a better grasp of the coding language. and it allowed me to think about how the program should work and not the particular code required to make it work in that way.
	I'm not exactly partial to coding.
	I prefer strategizing. The short answer is I don't type very quickly. I felt like I was hindering the team with this personal limitation. More importantly, I prefer dealing with the approaches to problems, not the messy details.

Did the initial designing of a testing strategy help in the overall design of your solution? Explain.

Test cases actually helped in pinpointing problems in our code

By writing the test cases first we had a better understanding of the problem

Yes, greatly. We added another test case toward the end of the project, and it revealed an error in the duplication algorithm.

Being aware of the many test cases that were possible helped us think of a reasonable way to use one function to test all cases. It also prepared us for what was ahead.

Yes, by coding to make specific test cases work (test cases which tested all the restrictions) it made it easier to be sure we were on the right track. And to see what part of our code wasn't working correctly if certain test cases didn't react the way they were supposed to.

I could see how it would be of benefit, but I think we're too new to XP to have really benefited from it. The project was to write a program that TESTS the validity of a password. As part of the XP approach, we're supposed to write a unit TEST to make sure that out program works correctly. I don't think we all understood that when we started, which tended to complicate things.

Yes, by looking at the test cases it was easier to visualize the flow of the application.

once we designed all the tests, we just went through systematically and made each test pass. Once that was done the program was done.

I felt the test cases were important in the design of the solution

Yes - We tested each "rule" of the password one-by-one, so as we went we knew exactly what was going on, what worked and what still needed fixing

Helped the overall design of the solution because it formed our thinking into designing it to pass the tests.

Yes - it is vital

We became much more clear to the problems to be solved and we were also be able find out some key points or problem areas which we had not covered in our original design

Yes, from the designing the test cases, we clearly remember what testing rules we need to include in our code.

The test wrapper was the first part we wrote, and it was functional when our validate function was just a dummy function. As sections were added to the validate routine, the new code could be tested with the existing test set, without the need to think of examples that would test the particular password restrictions as they were being implemented. It saved time

We knew what we had to solve and from there we decided how we were going to do so.

It made it easy to ensure all the features worked correctly - it was obvious when something did not work.

It was easier to plan for each step that we need to overcome along the way. Additionally we could test each small part that we developed, before going on to the next step.

Yes, it keeps us going to the right direction. We always try to code to accomplish the requirement of testing.

Do you think the final solution is better than what you or your partner would have achieved on your own? Explain.

Yes I believe it was better because I may not have had the time to complete this on my own.

Absolutely not. This was a simple problem, with many possible simple answers. I think each member of our team had a different idea of what was needed or what approach was best. I think it resulted in a mediocre solution. The benefit came in eliminating possible bugs. The navigators can stand back and see if the "driver" is forgetting use-cases or is checking the right conditions, etc. Ordinarily, the code would be compiled and run before the error was detected. Even at that point, the error may only be detected if the right tests cases are present.

I feel in this instance of a small function, working in a group actually slowed the process.

I don’t think the final solution is any better than we would have achieved alone. However, the pair programming led to many less compiling errors

So overall, our solo programs would have been roughly equivalent, but would not have profited from the modifications both of us made in the course of programming the pair solution.

I do think that our final solution was better than what me or my partner could have achieved, and I believe we came to this conclusion quicker. When working together we were able to complement each other and think for the other when one needed a break.

I don't think it was better than I could have done on my own, but I do think that it was done much faster.

Not really, since this was a small program,

Yes - My partner pointed out some cool strategy and syntax that help us to finish the project. In addition, when we thought we were done with the project, she thought of some more test cases

Yes, because there are two sets of eyes to see potential bugs.

Yes. Because of the final solution combines two people’s best suggestions

Yes - better

I think the algorithm may be better when two persons work together. However, for such a small program, it may be easier, more efficient, and organized to code on my own.

No - one person would probably have written better code.

About the same, but we did keep each other from getting too fancy.

I think so, the other programmer knew some aspects of strings in C++ that I would have had to look up or just work around. Since this program centered on strings, this was very important.

The solution is better than what we would have come up with individually because we basically took the best of our ideas.

I think it is the best that either of us would have done in the time we spent.

Better - the group contributed ideas I would not have thought of on my own

Better - during the development, we were able to discuss different solutions to the problems and then select the one we thought was the best

Better - We both made unique contributions

How did thinking about testing change the way you usually program (or why did it not)?

Instead of just jumping into coding the solution, we had to create a way for our program to test itself. This slowed us down initially, but sped up the overall process, as the testing was already in place in our code.

Kept us on track for this project. We only coded what was required

It placed the time consumed by testing up-front, and removed the constant need for new tests during the coding process. Being able to concentrate on coding without switching tracks to testing saved time and mental effort

It shaped my way of coding. Testing required me to do a small code at a time to meet the requirements.

I defiantly think it would help cut down on bugs

It forced me to program in smaller increments. I have a bad habit of coding large sections of code at once this made me code in smaller parts which took longer but was much more stable.

I usually write driver programs to test my functions anyway, so this was not much of a change for me.

They helped us understand all the possibilities and program accordingly

Rather than just getting it to work, I could focus on getting it to work well.

I think most developers think a about the set of requirements they have to fulfill, so I don't think it caused us to program differently. The "testing first" strategy helps to ensure quality. It doesn't alter the approach.

I have always thought about testing pretty thoroughly when I program. It is important to think ahead as to how a program may behave.

It was easier to break up the program into smaller, measurable steps that we could test against at each step of the way, rather then writing the whole program, and then testing at the very end and trying to figure out if what we did was completely right, or where it was broken.

All those testing cases will be carefully concerned when we implement the requirement. So, we can reduce a lot of bugs in advance, and the time for debugging the program is also minimized.

It was nice to have a more automated testing environment. Without it we would have run into a little more debugging trouble later. The automated tests may have taken time to start with, but definitely paid off once a majority of code was done.

I don't think testing changed the way I usually program, as I have always been somebody who uses different test cases and programs based on initial test cases. Although with this project, we directed more thought on our test cases and coded more specifically with our test cases in mind.

I learned that one of the potential disadvantages of my traditional way of programming is that it may be less efficient. When we fail to pass the testing after completing our code, we need go back to modify our code and this may introduce additional new bugs due to the changes. Therefore, whole system may need to be thoroughly tested again. The new method of testing eliminated this problem.

By thinking about testing, I concentrate on the testing cases which I need to solve.

It forced me to think about what needed to be done before doing it

It didn't really as that is how I look at programming, which is trying to visualize the flow of an input through the code and generating code that implements this flow.

It made me design one function that could be tested, instead of splitting up the task. Debugging was easier, provided by the automated testing.

What did you not like about this exercise?

Pair programming - I can see how it would work on a larger project, but in this case it just took a lot of extra time.

I am not used to starting coding until I am ready for it. In this assignment, since we have a time limitation, I had to start coding sooner.

Nothing

The combined ideas helped coding, but it also caused some conflicts when one of us wanted to solve a problem one way and the other another way. Explaining a possible solution to the other person was sometimes problematic if they didn't immediately understand what was being explained

Too much discussion

Having only one computer could limit the progress over development in that with two computers, one person could be researching something

It can be a little tough watching somebody else code something you would never do.

Nothing - I enjoyed it

giving up control

The lab computers take a long time to boot?

Nothing

Pair programming breaks down a bit when it comes to designing algorithms from scratch as one has a hard time helping the other with the algorithm they have not thought up.

I was sometimes left out of the coding when I did not understand what was being written.

Everything needed to be discussed, including variables names, if statement structure, coding standards. It just got out of control,

Too much disputing about what would work and what would not

Frustrating due to strong individual coding preferences

It was a bit like a programming assignment

It was strange to ask to use the computer

I had no problems with this exercise, and did not not like it.

There are probably other programs that might better demonstrate the usefulness of XP development strategies. One of the web sites that we read suggested that pair programming is not appropriate for minor projects. I agree with that whole-heartedly.

What did you learn from this assignment?

Automated testing should never be compromised.

People looking over your shoulder can help fix errors quicker.

Competitiveness actually worked in our favor, since we were looking for ways to make the program work better and not ways to show each other up.

I learned being a bit more specific with test cases and using them to our advantage and to guide our coding practices. I also learned the value of being with another and programming with them.

Every programmer has his or her own way on programming. Everyone has his own "style". When we do the pair programming, we need to accept the other's way.

Pair programming can keep the team on track as far as following a development process

By watching somebody else program I saw some tricks I may try in my coding later.

It helps a lot to have someone looking over your shoulder. Almost every syntax error we had was caught by the navigator each time

Coding together can accomplish far more than do it alone.

Pair programming is easier said then done... More time needs to be spent in planning, to make sure that everyone is on the same page. We did not spend enough time planning, and there fore had to rewrite a large part of what we did.

I saw the value of pair programming, and finally put many of the abstract XP ideas we had been discussing in class into use.

It is extremely beneficial to have another programmer watching what you type

There is less time spent in debugging in pair programming, as more bugs are caught during the initial code writing

Pair programming can be very efficient. I noticed a lot of the small things that my partner didn’t catch right away and vice versa.

It is difficult when you disagree about an implementation or one person refuses to accept the other's ideas

Pair programming is not easy

I have learned how to do team work and have realized advantages of pair programming, that is through team work, we could find best solution to the problem to be solved. In addition, I also learned the importance of initial test case design.

Pair programming will reduce the defect of program and minimize the time of development. The final solution will be more efficiency because it combines two people’s talent.

I will probably use some of the techniques in my future programming activities

Sometimes others will have better ideas for a particular part, and I need to let them do their thing.

Two heads are better than one

If the industry decides to shift to XP type development, I should probably learn how to type faster.