Self Critique
What did we do well?
IDB4
In the final section of IDB, our team dynamic solidified and we enjoyed our most productive two weeks of the project. We planned ahead, clearly delineated tasks, and worked effectively together. We met frequently as an entire team and communicated clearly via Slack and Github. More than any other section of the project, we felt that IDB4 was our most productive. We feel that, though we have areas to improve, we're riding out the final section of the project on a positive note.
IDB3
Before we started this section of the IDB project, we met as a group and split the requirements into stories. From there, we split the stories into smaller, more manageable tasks. In addition, we assigned labels to each of our stories and issues and added them to our project boards. Though we've followed this format throughout the IDB project, we made an effort to more thoroughly review the project rubric and requirements ahead of time and cleanly divide it into discrete pieces. Because of that early logistical work, we were able to smoothly segue into implementing the project. In addition, we did a good job of starting the project early and tackling big challenges first. We learned a lot of lessons from IDB2 and the final days of this project were far less stressful than the end of IDB2.
IDB2
We were proud of the planning we did coming into this part of the project. During this project, we were able to focus heavily on new material and barely had to rewrite old code. Because we completed IDB1 using React and we pulled our data from JSON files, in IDB2 we were ready to pull from an API and use its JSON response instead. In addition, though we were not entirely content with how we split up material this time, we were able to identify "project leaders" or "section leaders" who guided different components of the larger project. Like last time, we relied on Slack for communication and found it invaluable.
IDB1
One of the aspects of the project that we felt we accomplished especially well was dividing up tasks. Before we began development work, we met, created stories, and divided responsibilities. We then divided ourselves into teams of two or three group members and claimed pieces of the project. Dividing up the work made it slightly more challenging to keep up with the work other subgroups were doing, but we partially rectified that by having members of other subgroups review pull requests and by holding cross-group meetings. In addition, we did a good job of meeting our self-determined deadlines and wrapping up development on time. Finally, we heavily utilized Slack. We found it to be an excellent tool for communication.
What did we learn?
IDB4
In IDB4, we learned far more about how to work effectively as a team than we did in other sections of the project. We learned, perhaps unsurprisingly, that people work best on areas of a project they are personally passionate about. We learned the importance of tracking bugs using Github issues and closing them in commits and with pull requests. We saw the benefits of discussing issues on Github firsthand and gained an appreciation for generalized design solutions. In addition, because we spent a significant amount of time cleaning our repository and beautifying our code, we learned more about how parts of the project beyond our specific focus had been implemented.
IDB3
In IDB3, we felt that we gained a better understanding of higher-level software engineering concepts. While implementing searching, sorting, filtering, and pagination, we learned how to better use components, more about the relationship between frontend and backend, and how search works. In addition, now that we were adding tools to each of the model grid pages, we thought much more about designing our site around user-oriented features and focused more heavily on the user experience our site' visitors would encounter.
IDB2
For this section of the project, again, our team had to learn how to utilize new tools. Scraping, databases, and API setup was new for most of us. We spent a lot of project time working out how to integrate tools like SQLAlchemy, PostgreSQL, and TravisCI and how to best pull data from our three data sources. Like IDB1, IDB2 was definitely a learning experience. As we continue working on this project, we are still looking forward to our team gelling and settling into more permanent roles.
IDB1
Most of our group members came into this project not knowing how to use React, Gitbook, Slack, and many of the other required tools. During the first week of IDB we overcame a steep learning curve, but by the end of the development period, each member of our group had learned all of the tools. Feeling confident enough to work on any part of the project was extremely gratifying.
Another part of the project that we were excited to have learned how to use was the Github project board. We initially put issues and stories in the same project board, but after that became too cluttered, we moved stories to a second board. Over time we developed a set of "best practices" that we plan to use for future projects.
Finally, for many of us, this was the first large-scale project we had worked on, but over the past couple of weeks, we have learned to collaborate efficiently and effectively as a team.
What can we do better?
IDB4
Our biggest realization from linting our repository was the importance of having and enforcing consistent code quality standards before merging code into the master or putting code into production. Though we've done a good job of making sure that code must be reviewed and approved, and that a TravisCI build has to pass, before it gets added to the master branch, we did not enforce standards related to variable names, tabs and spaces, and JavaScript minutiae. This meant that our linting was, at best, slightly disorganized. We also did not initially create a consistent standard for commenting code and maintaining readability, and creating a standard later on ended up becoming one of our main sources of confusion. Our lesson from this section of the project is to create guidelines before writing code with a group and force members to stick to those rules.
IDB3
Though we've felt like we have had good inter-group communication thus far in the project, we've found it difficult to dole out tasks to each other. It isn't uncommon for an important group conversation to happen between two or three members outside of Slack. Our communication is still strong, but there are signs of it wearing around the edges. One of our goals for IDB4 is to meet more often so that group members don't become faceless people online.
In addition, we've become accustomed to fixing problems on the spot. That itself is actually a good thing – we confront bugs and issues that arise head-on, but it means that often we don't log problems that appear on the site. We've found that it's important to have a record, both for posterity and our own reference, of problems. It's not uncommon for us to run into similar bugs multiple times and having a place to look or code to reference is invaluable. Our other major goal for IDB3 is to meticulously log issues as they arise, even if we plan to solve them immediately.
IDB2
The biggest problem we had in IDB2 was underestimating how much work we had to complete. Because we set ourselves up for a smoother IDB2 experience than some other teams, we began to rest on our laurels. We assumed that we would not have much work to do and were comfortable pushing off work until later. Though our situation could have been much worse, we failed to expect how difficult the last few days of the project would be. We forgot about the inevitable "October Surprise" we would get from the rubric requirements (this time – needing to integrate TravisCI and add symbolic links) and by the time we heard about the extra tasks we would have to complete, they just got piled onto the other tasks we had known about but had assumed would be easy. Our biggest takeaway from IDB2 will be to start early. No matter what we expect the project to be like, starting early will set us up for a successful, stress-free finish and give us more time to react to change.
Because we had to triage tasks towards the end of the projects, each of the members of our group started keeping lists of tasks we need to complete at some point along the projects. Because we are building rapidly, we are not always building sustainably. The advantage we had coming into this project from the last one is slipping away. Before starting IDB3, we will again have to go through our codebase and prepare for the future.
IDB1
Though by the end of the project we were happy with our project boards, we wish we had figured out that aspect of the project much earlier. In addition, we did not do as good a job as we would have liked estimating and keeping track of how much time we spent on different stories. We plan to use a tool like PlanItPoker to divide stories and we plan to be more scrupulous about keeping track of how long we have been working on a task.
In addition, we could have done a better job connecting related issues and referencing and closing issues from commits and pull requests. Frequently we had to go back to issues that we should have used commits to close and close them manually. One of our goals for the next phase is to use a commit and pull request workflow to ensure that we are able to more effectively use issues.
Another related problem we faced was not labeling issues properly. This was partly due to the fact that some of our stories were initially flawed and we had to go back and change them. Nevertheless, we want to better use labels in phase two.
Finally, writing clean code is an area we have a lot of room to improve in. Before we start the next phase of the project, we plan to go through our repository and clean it up.
What puzzles us?
IDB4
One aspect of the project we've given a lot of thought to in IDB4 is how to display large numbers of data points in a human-readable, helpful, and interesting format. We've confronted this issue twice in this project – first when we redesigned our District details page to include an increased number of Census data points, such as computer ownership and internet connectivity, and second in the visualization component of the rubric. Though we are excited about the work we did in this section, we recognize that this is an area we have room to improve in. The notion we're fighting against is that "design sense" is impossible to learn.
IDB3
One issue we've confronted in this section of the project is how to set time to edit stories and material from previous iterations of the project. At the outset, we planned to make some changes to some of our model details pages, and though we were happy with the results of those alterations, much of that work has been put on the back burner. Between now and the conclusion of IDB4, we will need to figure out how to properly integrate "old work" into the project and how to properly triage what we have to do.
IDB2
One thing that puzzles us is how to equitably split up tasks among members of a large team. In IDB1, we wanted everyone to be able to work in a full-stack role and focus on models, but for IDB2, though we tried to maintain the earlier breakdown, we faced difficulty ensuring that the burden was shared equally. Frequently, a single member of the team would be forced to go above and beyond to carry the team as a whole. Though that's not unusual on large teams, and though all of us appreciated it when someone was willing to take the lead, it is important for a healthy team dynamic that everyone feels empowered to contribute and innovate.
IDB1
There were two big aspects of creating a large collaborative project that puzzled us. First, we found it difficult to create a consistent coding style throughout our repository. In addition, we were unable to create a pipeline to automatically pull and build our project on the production server. We plan to implement fixes for both of these in phase two.