This report is from the Princeton Student Events Calendar project, which was created in Spring 2010 by Ethan Goldstein, Samantha Hantman, Dana Hoffman, Adriana Susnea, and Michael Yaroshefsky, who was the project manager. It is presented here with their kind permission.
From the beginning we had strong planning skills. We immediately laid out our major deadlines, large milestones along the way, and what features we thought should be implemented at each stage. We purposely made a very aggressive schedule which forced us to spend a lot of time working, even in the beginning of the project. We knew it would be difficult to schedule meeting times with five people, so we also made the decision to have consistent weekly meeting times, including an all-day programming session on Fridays which helped keep us focused and driven to reach deadlines at least twice a week. Setting aside an entire day to solely work on the project together was really helpful for moving the project along. Also, with five of us, we knew that we would need a better organizational structure for our individual and group responsibilities than relying on email or mental to-do lists. So, we set up an account with a website that allowed us to keep track of group milestones, individual to-dos, and how much time we all spent working on the project. This way, dividing up tasks was easy to do. For the most part, we stuck to our initial schedule throughout the project without making any drastic changes. However, we probably could have done a bit better planning the last weeks of the project. We didn't quite anticipate how much debugging and polishing needed to be done, and how much work we would have for other classes during this time.
Overall, we were successful with our milestones. We had set four levels of features that we were hoping to implement, in order of increasing complication and decreasing necessity, and we accomplished the first three. The milestones helped to break the project into manageable pieces and kept us on track throughout the project. Early on, we decided to tie our milestones with the TA meetings so that we had self-imposed deadlines each week. We met our first few milestones exactly, and often even had features for future milestones done early. We felt that, towards the end, we started to incorporate additional features into our project that we realized were important but had not accounted for in the beginning, so we started to fall slightly behind. As we dealt with modifications and bugs, some of the features for our final milestones fell slightly behind schedule. However, we had all of the features critical to our design implemented several weeks before the deadline, so the work for the final few milestones consisted nearly entirely of improved usability or other bonuses that were not actually vital to the calendar, and thus could be implemented whenever we found time because other features were not relying on them as a foundation.
Most of us had little to no experience with the languages and tools that we were using for our project, so in the first week we decided to divide up the material that we needed to learn and give presentations to the rest of the group about them, so we could each quickly get up to speed. We presented on Mercurial (our version control system), html/css/jquery, python, and django. These presentations were very helpful to get everyone familiar with the tools we were using. This project has been a huge learning experience for each of us, and now we all feel much more comfortable with the particular languages and tools we used. Since we adhered to our milestone system well, we were able to thoroughly test each section of the project before moving onto the next. By the end, the bugs we had left were all small, and we were comfortable enough with the language and how we had implemented the site that it was easy for us to look through the site and identify areas that could be vulnerabilities and fix them.
Here are some quotes from members of our group about the surprises that we encountered along the way:
-“Working with so many people is both a blessing and a curse! …There is always someone who you can turn to for help, but scheduling a time for everyone to meet is a disaster!”
“Django is wonderful. I was constantly surprised by the tools Django provided to make our lives easier, such as setting up convenient error pages, providing date and calendar functions, and connecting the urls to the views. In contrast, I was surprised how difficult it was to find answers to simple questions on the Django site or elsewhere on the internet when there were small bugs or basic issues because we were new to the language. I was pleasantly surprised how willing everyone in the group was to devote large amounts of time each week to working on this project and taking on additional jobs, and less pleasantly surprised to discover how difficult it is at Princeton to find a time when five people can all meet together.”
“Well, every time we received a task that we had no idea how to do and then figured it out on our own, it was a really pleasant ‘surprise’. I would say that everything went smoothly. We didn't have any problems bigger than the server being slow sometimes.”
-"I was also surprised by how easy Django made things. Unlike in php, where you have to code everything explicitly, Django took care of a lot of the important work for us. I was especially surprised when I realized that Django's form handling automatically prevented against SQL Injection attacks, which is something I've always had to worry about in php."
We made several choices that we feel were very significant in helping us to complete our project. We all agree that setting aside time each week to work on the project together was incredibly useful. We all knew that the rest of the group was relying on us to be there, so we all made a consistent effort to attend. We're also very happy with the tools that we used, namely Django and Mercurial. Using Django was a great choice because it has a quick learning curve, a lot of built-in functionality, and well-written documentation. One of the best choices we made was to have five separate development sites on the server so that each of us could directly see our changes as we edited our files, but we did not interfere with the chances and progress of the other group members. In terms of our design and code, our choice to discuss the handling of multi-day events right at the beginning was very helpful, because we were able to completely structure the entire rest of our project around that, and now we feel that our calendar was successful in having the multi-day functionality that we were hoping for.
If there were more time, we would add back some of the features that we originally thought of adding, such as tags, alerts, and recommendations, but decided not to because we wanted to make sure we had enough time to have all of our basic features working perfectly. We would also continue testing and polishing, because there always seems to be new areas where we realize it might be better if something behaved slightly differently. It would be nice to do more usability tests as well. We made changes along the way based on user input, but there are still some smaller details that we could take into account, like which links are clicked most often in our dropdown menus in order to determine the order that they should be listed in. There were also several scripts that we downloaded from the internet, such as the date/time picker, that worked well but not exactly the way we wanted, and if we had more time we would probably go back and modify the code that was given to us. Lastly, it would be nice to spend more time looking at and understand other people's code. We were all very busy with our own sections of the project, that many times there were other functions and files that people wrote that the others of us never looked at. More time would give a better understanding of all the facets of our site.
Developing in a group is challenging, especially coordinating coding styles and modularity. Although we loosely agreed on certain coding standards at some point early on, we did not strictly adhere to them throughout development. As a result, indentation and use of single vs. double quotes may not be consistent. Furthermore, we designed with modularity in mind, but because most of what we were doing was learning while coding, not enough pre-planning could be done to ensure that the code was designed according to the best practices of programming. Admittedly, whereas some parts of the code are elegant and intuitive, others are hackish, redundant, or otherwise imperfect. Instead of trying to clean up the code significantly, which would inevitably involve completely rewriting certain parts, and potentially breaking parts that were otherwise functional, we decided to spend our time during the final few days (and hours) finding and fixing bugs (digital chewing gum and duct tape). Because we plan ultimately to launch the site to the Princeton Community in the fall, we will have time to clean up the code over the summer. Doing so will probably sure up the code anyway, because clean code is usually less error-prone than hackish code.
As with any website design, significant portions of our site directly implement or rely on code others have written. We have kept intact attributions in this code where they occurred and have made efforts to mark code that was borrowed.
Overall, we're all very pleased with how things turned out and the way that we worked throughout the entire process. One thing that we would do differently next time would be to schedule the last few weeks better. Towards the end of the project, we became slightly less organized and our precise goals and milestones became less clear. Especially in the polishing and bug-fixing stage of the project, communication began to break down- we lost exact due-dates and people began polishing and playing around with parts of the code they had written without working through the central project organization website. Half way through the project, we should have re-evaluated all our milestones and timeline to bring them more inline with what was actually happening on the ground. Although we remained on-schedule, by working on the project for a few weeks we had a better sense of how things would progress and could better predict obstacles than in the beginning. Because we never updated our timeline/milestones, we paid less attention to them in the very end even though they were extremely helpful in the beginning few weeks.