Senior Seminar – eXtreme Programming Homework 5

Pair Programming Programming Practice Revisited - Summary

Comment on the original state of the testing facility for the downloaded file. How much work was it to get it ready for the new test cases? Was the design better or worse than the testing facility you provided with your original project.

• It wasn't very much work to get ready for the new test cases. The design wasn't worse, but the comments in the program made it hard to understand
• It was very little work to add test cases, we just added a couple more items and what their results should be and were good to go.
• The testing, I think, was way overdone and confusing on top of that. The way it was set up, printing out the string it was testing and the results made it hard to modify and the output was not really all that helpful (had to be checked by humans). It was much worse than the first project.
• Not much time at all was required for adding test cases. The structure already setup worked well, and allowed for additions easily.
• It really wasn’t that much work getting the new code ready for the new test cases.  The format of the program made it pretty easy to modify.
• They were missing a few test cases, so their testing was a little lacking compared to what we implemented in our version of the program, but their testing scheme was flexible and simple enough that we were quickly able to understand it and add all of the tests we needed with essentially no recoding
• The tests that were already in place, were very accurate and to the point. It was very intelligently approached and well commented. The code that they supplied already had enough test cases that we would be able to use for the new requirements of the program.
• Their testing facility in contrast with mine is the fact that they used many more testing cases than we did. I think a lot of them were redundant and unnecessary.
• The testing was set up pretty thoroughly on the one that we downloaded, so it was pretty easy to look at and add / change the test cases. 
• Although the testing facility provided from downloaded file worked, we felt that there were too many duplicated codes in this code segment. For each testing case, it has at least two lines of code to perform testing. We refactored it by using an array structure to store testing cases. On the other hand, it was better than the one we used in our original project. In our original project, we did not do a good job in providing test utility due to fact that we failed to realized that we needed to do so. Fortunately, through this exercise, we realized this problem and we got a chance to fix it (this may itself indicate the advantage of pair programming, that is, pair programming and team work can help to find the problem early).
• The design of the test facility was excellent , the only issue was there was a lack of documentation on how the pieces of the test facility interacted. The design was better than the one we provided in the original project, as it was easier to manage test cases, however our test facility was easier to add new test cases.
• First, its algorithm and structure are very concise and clear. We very easily found the right place to add the implementation of new requirement. Second, the program does not have a user interface that allows Tester to dynamically input test case. If tester wants make any change to test case, the tester has to change it from code, which is not very user friendly. So we added an interface to the downloaded file, so that after displaying the result of all static test cases, the tester has a chance to input test cases dynamically. After carefully study and read the downloaded file, I think the design is better than the testing facility we provided with our original project.
• It worked just as well but I don't think it was quite as easy to use as the one on our original program.
• The testing facility was not well written.  It was quite ambiguous how it worked.  It took us several minutes to figure out the scheme, make it a bit better, and adapt our tests to it.  The design was not as good as the one I helped develop in the original project.
• We didn't spend too much time trying to modify the file. We simply added another "if" function, and replaced the old test cases with new ones. The original downloaded file was well structured. The design is much better than what I have on the one I worked on. The structure on this downloaded file is very simple and understandable, therefore, it saves us a lot effort. The one thing in my original program which is better than the downloaded file is the testing cases implementation part. The downloaded file has the testing cases "built-in", which meant the user can not test their own test cases, but ours prompted the user to enter their own tests.
• The testing I believe was more thorough than our tests, as there were about 40 test cases in this program. It wasn't too difficult to get the program ready for new test cases, we just implemented them sequentially. We added another set of loops to check for the vowel case.
• It took very little work to customize the existing testing for our purposes. I liked the test structure my first group developed better because it showed not only the attempted passwords and results, but also what the results should be, so checking the results was a lot easier. The structure of our original testing seemed more efficient to me (we used a password array and a for loop, while the the new project had a pile of if statements - one for each password).
• The testing facility was well developed.  The test cases in the testing facility already provided what was needed for the refactored changes.
• I think the design of the downloaded file is better than the testing facility I provided with my original project. My testing facility didn't have all the test cases hard coded in the program (then it isn't a testing facility is it?). The code is much easier to understand. We just need to code a new requirement and we are ready to test new cases.
• I think that the test cases were not as thorough as my original team's, but it was very easy to put in more test cases, and to modify their code.
• I think that it was a little better, it seemed to be a little simpler and cleaner.
• It was very easy to add new test cases to the code and modify existing ones. However, many of them seemed redundant. On our code last week, we had one test case for each possible error. The new code had over twenty test cases. The main problem with the testing facility is that it made you determine if it ran successfully. It printed out the result of each test case on the screen. Then you had to determine if they were successful or not. Our version of the test facility simply printed out "All tests passed" if everything ran ok. If a test failed, we displayed the test that failed and what it was designed to test. I feel that our method made it quicker to test changes to the code.
• There was documentation, but it was not really relevant in understanding the project. Having worked on a similar project meant that I did not need to look at their documentation to know what was going on.
• The test facility was a bit confusing and the output messy. We spent too much time trying to understand how it was testing, and if the results were accurate. Their attempt to provide failure reasons for each rejected password might have been better rolled into the verification routines themselves, rather than hard-coded into the output of the test suite, since telling why verification SHOULD fail is not the same as verifying that was why it DID fail. My original program had far simpler testing, which made the code easier to read through, but the test results could have been more informative.
• Since the original state of the testing facility was well written and working properly, it did not take much work to get it ready for the new test cases. We changed the failed message printout to include the password string that was entered. Then we added some additional test cases to exercise the new requirements. This design was better than the testing facility we provided with the original project, because we incorrectly used the result from the password function as the reported output.
• The original state of the testing facility was ok, they simply output the result of the function instead of displaying whether it should have shown false. if a test should turn false the the test should display passed. that makes checking the tests much easier.  I felt my testing facility was better.

Comment of the documentation in the downloaded project. Was there any? Did it help you understand the implementation.

• The documentation was excellent, and did aid in my understanding of the flow of there application.
• There was a little documentation, but only a little was really needed. It did not help too much.
• The documentation was done well and done so after every 3-5 lines of code. The code was also written well so it could be understood. It complimented the code well.
• The documentation was limited, in that it only explained each specific activity inside of the password function. Documentation detailing the overall functionality of the program did not exist. This would be helpful for someone that is not familiar with the assignment.
• There was some documentation in the file but it didn’t really help that much.  The one part that needed it the most was the main function and it didn’t have much
• There was not much documentation at all in the project.  It took a few minutes to understand the testing.  The other parts of the program we altered were not hard to figure out.
• The documentation was sufficient to allow us to see where they checked each specification for the password. This made it easy to add ours in the best location.
• The project was well documented.  Each test was identified with comments.  The code was straightforward, and easy to understand.
• The code had some comments that helped find the correct placement for the changes
• The Documentation on the project is clear, nice and to the point. It really helped us to understand the implementation.
• There was minimal commenting in the program, and the comments that were there were not very helpful. Their coding style and the algorithms they used were very straightforward however, so we were able to understand how their program was working pretty much right away
• Did not notice much of the documentation, I believe there was some; but we did not really pay much attention to it, since the functions were so visible.
• The documentation was a little mediocre. It was very basic in what information it provided, and did not go in-depth into what was being done, in the more complex code segments. It helped a little, I think that we had to interpret a lot of the code, and more in-depth documentation would have helped.
• Yes, their commentary was very well written. It definitely helped me to see the functionality of the program more easily than seeing one without that kind of commentary. The commentary was very involved and detailed. It was quite helpful.
• The file was very well documented It provided a lot of detail about how they addressed each implementation criteria 
• Yes, the download project does have comment of the implementation. The comments gave us a lot of hints so we didn't have too much trouble in reading and understanding the code.
• The documentation in the downloaded project is very good. It provided proper description right before each code segment in which a business requirement is implemented. Therefore, it greatly helped us to understand the coding so that we were able to quickly start making modification in the downloaded project.
• The documentation that was in the code was very helpful. Mostly, it described the password checking function. However, their test cases were not documented well. They did not say what the purpose of each individual test was. If a test passed or failed, you had to figure out if it should have passed or failed. This also made it difficult to add the new requirements since we had to try and figure out what each test case needed to be modified.
• Yes, there was some well-written documentation in this downloaded file, and it did help us to understand the implementation in the program. Therefore, we could get into the structure of this program quickly and know where to code in the new features.
• The majority of the comments didn't help us to understand the code, though they made more sense after we'd digested the code ourselves.
• Yes, it was well documented and it helped.

Adding the requirement that a vowel be included might allow a simplification of the system (there is no longer a need to check that a letter and a digit appear). Did this allow a simplification of the code? Explain.

• No adding a vowel did not help to simplify, because even though we had a vowel, did not guarantee that we had a digit, or all valid characters. The only thing we could have done is check for a vowel first to "short cut" the checking routine.
• Yes, it allowed a simplification of the code. Did we spot it? No. We were very concentrated on getting the work done.
• The new requirement of the program, with the way that the code was written really didn't allow for a simplification of the code. We did, however, easily implement the new option because of the good documentation and well organized program.
• We didn't think of simplifying any of the previous coding, but probably simply because it was so easy to add the new features
• Yes, removing the haschar function from the testing function accomplished this.
• It still requires that a valid password must include at least one digit number and a lower case letter. This means you still need to check them.
• The new requirement did not simplify the code because the code iterates through each password, one character at a time to check whether or not a character is valid. Though a lowercase vowel is required, other lowercase letters are still required.
• We didn't catch this simplification.  We implemented a third test that was called when a lowercase letter was found.  Our method was obviously not the best solution.
• We did not take the simplification route
• No, we implemented this by added a vowel check to the existing checks. It wasn't complicated, but it didn't simplify the existing code.
• I guess now that it allowed simplification, however I neglected to see that when correcting the function
• I’m pretty sure there was still a need to check that a letter and a digit appear.  At least that’s what the assignment says.
• No - According to the requirement; we still need to check if the password is a mixture of lowercase letter and digital number. So the need to check that a letter and a digit appear still exists. Adding the requirement that a vowel be included actually added a more strict rule on system, the implementation of the code will be even more complicated than before.
• This did allow simplifying the code a bit, but we really didn't want to try and do so. We knew speed would not be even close to a factor and it may have messed something else up in the project had we changed the original code. If the passwords became thousands of letters long, we would start to look at such changes. 
• I don't think adding this requirement would simplify the system. It may change the way we implement the "letters" testing part. However, the feature of testing appearance of digits can not be avoided.
• No, it is not really simplifying the code. Even though we don't have to check the lower letter anymore, we still have to check for vowels which make we add more code to it. Yes the system is simpler but the code stays the same.
• Since the requirement is now that the password include at least one vowel and one digit, there is still a need to check if a digit appeared. We just added a function to check if a character was a vowel.
• Yes, it did allow for a simplification of the code. However, I did not notice that until I read this question (of course we already mailed our project in). We could have removed an 'if' statement that checked for a character greater than a and less than z.
• Yes. we changed the Boolean flag for finding a lower case char to a vowel Boolean instead. If you find a lower case vowel you have also found a lower case character
• Our hasVowel() function overlapped the functionality of the prior hasChar() function, so we could have removed the hasChar() function entirely, but due to lack of time we did not. The removal would not have greatly improved the performance of the program. Besides, with the customer already changing their mind about password rules, it seems possible they might wish to change again and go back to the simpler hasChar() method, giving us a good reason to leave the redundant routine in.
• It did not allow a simplification of the code. We just added another testing loop to check if there are any vowels, and there had to be at least one. If there was none, it would return an error. (Similiar to previous test loops)
• Yes we only checked for vowels, and no longer checked for letters.

How did this exercise affect your view of your personal coding/documentation practices? What should you change to make yourself a more valuable team programmer?

• Documentation is quite important for shared code.  It can be one of my weaknesses at times.  I should learn to document better to make myself a more valuable team member.
• First the exercise let me realize that designing test cases and a test framework is as important as designing the program. Second the documentation is a very important aspect of developing software. It can not only help the original programmer to remember the implementation but also can help the team to integrate and maintain the software in the future. Use meaningful variable and function names to help the team.
• Whenever I usually write code, I always try to make it as simple as possible and comment it well. This programming assignment simply allowed me to exercise my normal programming practices. This assignment didn't really change my way of programming all that much.
• There were two things that I noticed while doing this exercise. First, programmers tend to make programs unnecessarily complex, which is something I try to avoid. Secondly, the level of documentation in programs I have written are not up to par for a paired programming XP knowledge.
• This changed my outlook on writing comments.  They are good to write, in case other people look at your code, and it conforms to standards
• From modifying another's program, I learned a need to document my own code well. Because of the good documentation in the original downloaded file, we did our modification smoothly. Also, the design of the program should be clear. I think when you program as a member in a team, you are not only responsible for yourself. You are responsible for the whole team.
• The need for good comments was very apparent. I think I comment well enough for another programmer to understand my code so that if I return to a project after a long time, it will still make sense to me.
• This reinforces my personal documentation practices.  A well documented piece of code helps explain implementation details and sometimes why a particular approach was used when implementation was done.
• After this exercise, I learn that documentation is the key to be the better coder. Documentation is everything. Without documentation, no one would understand the code and it would be hard to maintain the code. To be a better team programmer, I need to document more specifically.
• It helps to enforce how necessary documentation and simple coding are. In the first download, it was very "overdone" set of testing routines, with not a lot of clear documentation, and it was easier to throw that out and start over with something new, so we did. The changes I should make are to document where necessary ( not just state the obvious, but the in-depth details) and to keep things simple, not go overboard just because something is "cool"
• The importance of clean and readable code was very important. On a larger program module, or one with more complex functions, commenting would have been very important to identify where the simplifications could be made. I understand why I need to be consistent in the way I code modules.
• It made me realize that I do have good ideas, but I should work on better documentation. Besides better documentation, I need someone who thinks like I do, or it's difficult for me to work with.
• I believe that more documentation needs to be done when working with paired programming and XP styles. It should be very important, or else more time would be lost in the process of just deciphering code. The documentation should also be orderly to be easily understood itself.
• This exercise showed me that it is very important to write understandable code and to clearly document it. Documentation is more useful when it describes the overall logic, not just the details of each line of code. I feel to make myself a more valuable team programmer, I should think from my teammates prospective and not assume that they can read my mind.
• It became very apparent how helpful good documentation and a clear programming style is when coding something someone else will be looking at and possible adding to or altering
• Well I realized I should probably document my code, even if I don't think any one else will see it. I didn't document the first part well thinking it wouldn't matter.
• I would not say that the project affected my coding/documentation style. I strongly believe in using ample documentation and I think it is essential rewrite code if you can get it to work in a simpler way.
• I think that my code is well written, and understandable, but I realize that I do not put in enough documentation. I think this project let me see that I need to comment my code more carefully
• Good documentation and cleaner code would have greatly reduced the time we wasted learning how/if the program functioned before we could begin coding.
• It made me aware that I should further study built it functions like strncpy. 
• A good documentation will not only help yourself in the future to recall what you have done for maintenance purpose or modification but also help your team members to know what you have written so that they can quickly pick up your code. It is obvious to me from this exercise that I should make some changes in my coding style so that I could become a more valuable team programmer. First of all, I should put more effort to provide good comment or documentation when writing code. Secondly, I should also learn more about common code convention and code guidelines so that I will be able to write clean and effective code, which can be easily understood by other programmers.
• This exercise didn’t really affect my view of my personal coding practices.  I did learn a lot about team programming though.  I’m not completely sure what I need to do to be a more valuable team programmer other than program in teams more often so I can get used to it.

How did the downloaded starting point hinder/help your ability to implement the required changes?

• It hindered it because we had to take the time to figure out what the code was doing.  Also, with the testing facility being ambiguous, we lost time trying to decipher it.
• The code downloaded was an excellent starting point with a highly modular design in which a new test can be added with relative ease.
• Well it was much easier to alter this file than it would have been to alter mine. More things were hard coded in my file. But this file did have 1 bug: one of the loops did not loop to the last character so it wasn't being checked.
• The code we downloaded was structured well, so it was easy to insert our changes without affecting the existing structure very much.
• It really helps us to implement the requirement since it has a similar logic to the new problem. We can easily figure out what to do for the new requirement. In the real world, cutting project into smaller pieces will help to solve the problem faster.
• I do not think the downloaded code hindered us. The changes we made were very simple and the code we modified was readable. However, on a large project it my take hours or days to get a good understanding of someone else's code.
• I think it helped very much, because most of what you needed was already
  coded for you. We only had to make a few small changes, and add a few more
  tests to get the newer version working
• It hindered making changes, mainly because we were unfamiliar with the code. However, the changes being made were not that complex, and that performance slow was minimal.
• It made it extremely easy to make the changes because the code was good enough that it could easily be modified
• The downloaded file was well structured. After we went through the code, we knew exactly where to modify. 
• The only downloading hindrance was the slow computers in the lab.
• Since the project was so simple, and since we were already very familiar with the project since we had written our own version the previous week, it really wasn't that much of a challenge to add the new features to someone else's program.
• It took some time to get acquainted with it, and there was an obligation to code in the same manner (switching styles as to not want to redo their code). It did make it harder (it was more like starting from scratch than picking up where the first let off).
• Our coding was delayed by our need to understand and verify the work that had been done before. We were unable to trust completely in the prior work and proceed blindly with our modifications, seeing the complexity of their code and incomplete documentation. When we found apparent problems with the code, we had to first test that the problems were real, and not just due to our incomplete grasp of the code functionality, basically adding test layers onto the existing test layer.
• The starting point puts in place a coding standards and also establishes an overall approach to the project's design.  There are many decisions that were already made, so refactoring the code takes significantly less time than starting from scratch.
• Reading somebody else's code was the most difficult part and actually implementing more code that conformed and didn't appear to out of whack with existing code. It helped slightly due to the fact as it a guideline, but it also hindered us in the same aspect.
• The downloaded starting point helped because we didnt have to retype code, and the changes only took a few minutes
• The download helped us implement the changes since it was such a simple design, it was easier and clear to see where we needed to make the necessary changes
• The downloaded starting point is clear and concise; it is very helpful for us to implement the required changes.

Would you have preferred to start with the code you worked on last week, or was the new code easier to use? Why?

• With the documentation it was easy enough to make the changes. I don't think it would have taken much less time using our original code.
• It would have been easier to use my code.  I was already familiar with the testing facility.  Also, it would have been faster to locate all of the sections of code that needed to be updated.
• Yes, I liked our test structure better, and our code was a little more compact. Other than that, the code we downloaded was good.
• I would have preferred to start with the code I worked on last work, for two reasons. The first reason is because I would have liked to correct the testing facility in my original project. The second is because I feel our implementation of the password function was more straightforward than this new code.
• I would refer to work on my code since I know what is going on in my code. Reading someone else is quite an experiment but I need to adapt to new styles (some of which I do not agree with). Reading new code might show what I miss in my code. But I would prefer to work on mine.
• I would have preferred to use our code. This is because the testing facility was difficult to modify and use. The actual password checking function was very easy to understand.
• Yes, I would have preferred to start with my code. I was familiar with my code and I understood it the best.
• I think it would have been a slight amount easier to work on code that I was more familiar with, but I was very happy with the code we worked on. The group who's code we worked on approached the original problem in a very similar way to the way my original group approached it. It may have been more difficult working on one of the other different groups. I think in general it is easier to work on something that you yourself have worked on, because of the familiarity factor.
• I would have proffered the code I originally worked on as I could have made the updated in a matter of minutes as I already understand the exact flow of the application.
• Since the download project has good documentation/comment and clean code, we were able to easily identify where the code needed to be modified and added. Thus, it helps us to implement the required changes. Personally, I do not have preference to start with the code we worked last week. The reason for this is that I am more interested in learning other programmers good code style and their solution to the same problem. I do not mind to put a little bit more effort to read other people's documentation and verify their coding meet the assignment requirement.
• I personally would have preferred to use the code I had helped to write, simply because I was much more familiar with that code, and implementing these changes on that code would have taken significantly less time
• I could have used either. Both code implementations were easy to understand. However, if I had preference, I would always choose to work on my own code first.
• It would have been far easier starting with my previous code, or with the code of someone whose coding and comment styles more closely matched my own, and whose abilities I was familiar with and trusted fully. Even starting from scratch and working from memory, I could probably have rewritten my entire program in half the time we spent reading through and verifying the function of the other team's code. Perhaps my prior work on the earlier incarnation of the program ruined me for impartially viewing another team's work on the same project. I had expected internal ego clashes within the pair, but maybe the bigger problem is external ego clashes between different pairs and their work.
• This file was easier, again because the code was changeable just by changing a few numbers rather than recoding much of the assignment.
• I think using our previous existing code would have been easier, because in my head I could imagine that the changes would only take maybe 20 minutes. I already had the mindset of our previous code in order to make the changes, so working it in with the new code was difficult.
• I feel more comfortable on the code that I worked on last week, because the code is built on my design, my algorithm, I clearly know how the code will work. It is much better than using other peoples' code. On the other peoples' code, I have to read and understand the code, then test it to see if it meets the previous requirements. It really wastes time for implementation of new requirements.
• Well I didn’t actually do the last assignment because I missed that class, however I did look at my partners code and saw that I would have much rather used his, because it was extremely well documented
• I would have much rather used last week's code. I was already familiar with it and liked the way it worked.
• I think that the new code was easier to use, then what I did last week. It was a cleaner, simpler design, and they did not try to make it too fancy, just stuck to the basics of the assignment.
• The code I worked on this week is probably much closer to what I would have implemented if I had been coding the project by myself, so the new code was definitely easier.
• The new code may be easier to use, I like the design of it which is very clear and easy to understand. The code we had last week does not have as good of a design as this new one.
• Original, because it was familiar, and it worked well. I was very familiar with what was going on and why.
• At the start, I would have preferred my code due to familiarity. In the end, I was glad that I used the new code. The non-repeating sequences in the new code were set up much better and more reusable than mine.