Blog Iteration 1

| No Comments

This is a blog entry about my group's experience with our first iteration of the language translator. During our experience with iteration 1, me and my partner had some things that worked very well and some things that didn't work so well during our development process.
One thing that may be obvious but helped us a lot was getting help from the ta's. Both me and my partner never used C++ before and even though it is like Java we still struggled with some of the concepts and the ta's really helped with that. Using the resources that we had was a big help when we were stuck on something. If a ta wasn't there to help us there was piazza, which was also helpful with our problems.
We also split up the work evenly, not just have one person do all the coding for the scanner and another doing all the test cases. We split it up so that each person gets a chance to do both so both of us had an understanding of how the scanner worked and how the test cases worked. This way, it didn't limit one person from helping with other parts so when there were bugs that needed to be fixed, we could both do it and not have me sitting there waiting for my partner to fix the scanner so that I could continue working on my test cases.
Another thing that was worked well for us was getting together in person to work on the project as well as working on it individually. It was easier to us to help each other when one of us was stuck on something since we were right next to each other and we could see the exact code that was running to find the problem instead of trying to explain online in an email. By getting together in person we were able to teach each also and better explain things than trying to explain it online.
Lastly a very important thing that helped us work though the first iteration was having a positive attitude, segmentation faults really tested that but by keeping a positive attitude we were more productive and were able to fix those problems and finish our scanner. At times when our code wasn't working like the way we wanted it work, it was very frustrating to have to go through the entire scanner class and work on it for 2 hours trying to fix it. But we kept a positive attitude and in the end we didn't just give up but kept going and found the problem and fixed it.
Aside from the good things that helped our development process, there were road blocks that made it difficult for us. One thing was our planning stage of developing. We didn't really sit down and try to plan out our scanner class so it really took us a while to get started and for things to really get going. We didn't understand some of the requirements that the scanner class needed so this also affected our first few test cases which were not testing things correctly.
Time management was also something that wasn't planned well enough. We struggled a little bit to get started on the project and also spent a lot of time on our scanner class which didn't leave too much time for us to work on our test cases. Towards the end of iteration one we felt rushed, which was totally our fault but rushed nonetheless.
Although we did spend a lot of time working in person on the project, there were some times when we didn't communicate very well with each other. We didn't agree on a style of writing before hand, so at the end one of us was using emulated pure block while the other was using begin-end pairs. Although it wasn't a huge deal, it was a waste of time for us to have to go through all the code and change it to be consistent.
Working in pairs was definitely better than working on iteration 1 by yourself. I'm sure that some people could have done it by themselves but for me, it was more beneficial to have someone to split up the work and also learn from. Working with a partner, made working through this part of the project a lot easier and will definitely make the rest of the project easier to do also. We both had the same understanding and mindset to get the work done, even though we started late and worked really well together.
For us one thing that I think we need to change is to do more unit testing on our code. We didn't use a lot of unit testing in our code, so that lead to a lot of hours spent trying to debug. We thought that our code worked one way but it was really doing it differently, so when we were doing the test cases, it made it painfully obvious that we designed our logic incorrectly. For me, I don't want to spend hours on end trying to debug some silly logic mistakes so our group will definitely try to use more unit testing.
Also our group needs to manage our time better, both starting earlier and making sure we have enough time to finish everything. I don't want to have to rush so much at the end so better planning on how we are going to spend time on something will make it less rushed towards the end. Since the grading system lets groups earn back the automated grading points, we definitely could have spent more time on the human grading portion to get that done.
All the things that worked well for us in iteration 1 will be things that we continue to use throughout the rest of the project. By using our resources that we have, splitting up the work in a way that both of us gains a better understanding of the project, working together in person and having a positive attitude are all things that worked really well in our first iteration and will be things that will continue to work well at the other iterations of the project so we will continue to use them.

Testing

| No Comments

Test

Recent Entries

Find recent content on the main index or look in the archives to find all content.