Common Blog

Common Blog

As requested by Dr. Chenoweth, we will keep a "common blog" where we document how the project developed in real time by noting significant* events as they happen. These events include standup meetings, issues, blockages, code progress and reflections on client meetings. This description will probably change as the year goes on and we refine the role of this page.

*significant - The meaning of this is largely up in the air.

Prior to classes

• Met with client for brief introductions and a more in-depth view of his vision of the project. The scope was restricted to routing cars on roads in urban areas. The project will be deeply integrated with the public Google Maps APIs.
• Standup meeting to discuss the role of GitHub in our project. We are going to attempt to do all documentation and product planning via GitHub issues and wikis.
• Met with the client to discuss technology choices, including AngularJs, Docker and Play Framework.
• Discussed potential use cases that don't fit in model - carpooling only with your friends.

Sept 8 - Sept 15

• We have spent our last few meetings discussing use cases for our service. If we had contacted Mike over the summer, we would have had a lot more time to brainstorm ideas. -Adam
• Sometimes we get sidetracked for several minutes at our standup meetings. We should save follow up discussions for after the standup. Also, we often end up arguing about things that we are actually in agreement on because of communication issues. - Carter
• Don't forget not to edit wiki pages while other people are editing. GitHub doesn't do version control for wiki pages. Discussions could also go better if we decide on things more people know. -David
• I think we should start writing more code, I understand that we should try to learn what to do and what Mike wants, but we should be less apprehensive, it’s okay to mess up a little, especially since we can learn from our mistakes. I also feel like we often get caught up in minor details during our standups. -Dan
• What went well in Junior project last year: We did a good job of defining what features were part of each sprint. There wasn't much ambiguity as to what we were supposed to be doing. What didn't go well: Testing. Nothing was tested thoroughly and many bugs cropped up because of it. Also, it was annoying that we had to coordinate between several different websites to do our tasks: { Google Doc, GitHub Wikis, Trello }. -Adam

Sept 16 - 23

• So far we are starting to pick up the pace. Using the Play framework is definitely the most difficult part of the project. -David
• Some thing we need to work is asking our client more questions earlier. He has been very helpful when we ask questions clarifying parts of the project. But when we don't ask questions about a certain part we let it sit there not working on it. -David
• Using Google Hangouts with our client has been very helpful. The Hangouts seem to be very productive overall. -David
• I think the client meetings have gone very well overall. However, I think we could step it up in terms of communications outside the meeting. We have gotten blocked a few times, waiting build in time in our sprints to use them appropriately. - Carter Travis CI has really helped keep the project tested when we integrate. We have found quite a few bugs during integration that didn't occur before. Also, it helps to have a clean slate every time to know that new people can compile the code if nee for a client meeting to occur. -Adam

Sept 24 - 30

• Using mostly GitHub is definitely better than Junior Project's like five website approach. I do like that we have the ability to have a Trello like board integrated into GitHub. I believe that last year may have went better if we had a repository of all the links, like Moodle. Everything was scattered around the internet with no single place to remind us where everything was. We would forget simple things just because they weren't very visible. Having everything in either GitHub or linked on GitHub has really made it much easier to find things. -David
• One of the things that I think we've done great is focusing on testing and process early. Even though we don't have much code yet, we have automated code building and testing with Travis and code coverage with Coveralls. However, I think I personally may have invested too much time into this process. Last year in Junior project I had produced far more code by this point in week 4. This quarter I've spent about as much time reviewing pull requests as I have writing code. I think this is both good and bad. - Adam
• Pull requests/code review have been a big part of our process. They provide a great opportunity for us to familiarize ourselves with parts of the code that we didn't write, allowing us to assist each other more easily on our respective features. The reviews also provide a forum for teaching each other what we have learned about play framework, reducing the amount of time spent ramping up. - Carter

Oct 1 - 7

• Communication with in our team is very good. Our team mainly communicates in three different locations GroupMe, in person, and GitHub. Groupme is mainly for quick questions or reminders. Since the application can send notifications to phones and web. In person we conduct standups (while sitting) and follow up those with work meetings. GitHub is where the major project planning, validation, and documentation occurs. - David
• Our team communication exists in several different ways: in person standup meetings, text messages/groupme and GitHub. We have been increasingly using GitHub the past two weeks and I'm really enjoying it. It allows us to organize our discussions and keeps a record of the discussions that people have had on various topics that I wasn't involved on. For instance, this last sprint, I worked mainly on the backend server and the iOS sample app, but I was able to view Carter and David's discussion regarding the webserver and webclient on their GitHub issues and pull requests. - Adam
• It is great that we got a working demo. I feel like we worked too quickly this sprint and we should slow d own and make sure that our code works. I also think that we need to fix up some of the code we hastly written to complete the demo. I do feel like the team is communicating better though. - Daniel

Oct 8 - 13

• Our code quality is moderate. At the beginning of the quarter, we strived to have extensive code coverage and code review. However as our clients demands have increased at an quick pace, those original desires for quality have fallen to the wayside a bit. - Adam
• I think that we let our velocity get a little too high last sprint such that we weren't able to stay up on test coverage. We ended up having to take an extra week to go back and un-cut corners from our demo. We have a good framework in place to ensure high-quality code (C.I., pull requests, etc.), but we need to make sure we build in time in our sprints to use them appropriately. - Carter
• Travis CI has really helped keep the project tested when we integrate. We have found quite a few bugs during integration that didn't occur before. Also, it helps to have a clean slate every time to know that new people can compile the code if needed. - David

Oct 14 - 27

• It looks like we are on track to creating a minimal viable product. I am worried about our lack of support for subclusters though. I feel like it is going to be harder to add support for the longer we push it off. I am also concerned about implementing authentication for the same reason. Also I think that we should try to have members who have not implimented the sdk's implement the sample apps to provide feedback - Dan

Oct 30 - Nov 7

• The overall SCRUM process for our group has improved since the beginning of the quarter. We have been more efficient with the time and cut the amount of time for SCRUM meetings. The process has moved more to what has changed and less to what is blocking people, which has helped and more of the meeting is focused on how to improve the quality of Pathfinder.
• I think our process has gotten a little looser. We are spending less time planning and more time executing. I think it is happening because we are getting better at planning and taking responsibility for our work, so we don't need the overhead of the formal process as much any more. Furthermore, we've all been under a lot of stress recently but I think it has helped spark us to get to the level of a minimum viable product. --Adam

Nov 8 - Nov 11

• Our meetings have become much less planning based and much more implementation based. I think this is good, it shows that we all have a consistent plan in our head for the project and it is modular enough that we can each work on separate parts independently. However, I worry that we may be deviating from the core idea of the product because of this and are spending too much time focused on auxiliary tasks. --Adam