Division of Work

In terms of designing our software, we felt that it makes the most sense to split up into two teams, a frontend team and a backend team. Seeing as we had five people in our group, two would work on the frontend and two would work on the backend, with one person acting as a “swing man”, helping out whichever team needed help. We are using Github issues to keep track of tasks and assign them to people. This allows us to categorize tasks that need to be completed, and provide a public way to display what we are working on, as well as a history of what we have completed. We can have discussions directly on the issue, providing an easy way to see the history of design decisions and changes that were made. Perhaps most importantly, it allows easy integration into our development process. Since we are using git as our version control system, and hosting our repository on Github, Github issues allow us to point to specific commits when bugs were fixed, or features were implemented.

Design Decisions Documentation

We have also been using a blog, hosted on Github Pages, that serves as a way for us to document design decisions. This means that if we are lucky enough to have this project become popular, future developers can see why we made the decisions that we did, and hopefully understand our thought and design process more fully. Although we have not yet quite reached as formal of a process, we would like to model this off of the PEPs (Python Enhancement Proposals), which clearly document design decisions in python. One of the nice things about the PEPs is that they document not only features, but rejected features as well. This allows for developers to see why things were NOT implemented, which is just as important, if not more important, than seeing why things were implemented. Over break, I am going to try to take some of our design decisions and formalize them a bit more into a document that provides more clarity into our thought process.

Trying to Meet Deadlines

The last part of our design process is the actual development that has been taking place. We have been trying to set weekly goals in an effort to motivate us and provide soft deadlines during this yearlong process. While we have not always hit our goals, they have been effective in helping us focus our efforts on specific tasks for the week, and providing a clear way to see what features are important and should be implemented first.