7 Developers and 1 problem to Solve
The Framework
Being a student in Lambda, a fast-paced computer programming Bootcamp, we finalize our learning with a month-long project. Where everyone placed on a team has been through all our core units and has now been tasked with a real-world problem to solve on a cross-functional team comprised of DS and WEB students.
We worked with the non-profit organization Human Rights First. An independent advocacy and action organization that takes on the task of holding the United States accountable to its ideals. They focus on putting pressure on the U.S government and private companies to respect human rights and the rule of the law. Specifically, one area of work they are developing is a way to visually display incidences of police violence within the United States. This not only helps create a place where knowledge can be found for people who need it most such as journalists but it also creates a resource to help understand the trends of police violence and where they might be.
To accomplish solving these crucial issues our team inherited a legacy project that directly looked to solve this problem and help Human Rights First. Our product was to improve a landing page that displayed a map of the United States that showed pinpoints of incidences of police violence. With Zoom in capabilities, we were able to see links to articles of incidences.
Upon starting this project collectively as a team we wanted to try and make the best product possible because we knew how important this problem is and how much it helps Human Rights First that we move forward on this task.
The RoadMap
The planning phases of a project is easily the most crucial part. We took time to create user stories and were committed to a high level of breaking down tasks to make sure we started this project off right. In creating user stories as a team they needed to be done in the scope of the user. Focused on specific features a user would want to have with this product. We took what we knew about the product and what our stakeholder had told us of his vision for the product to help drive our thought process. We also used this time to explore the deployed product to assess what we thought was working and not working. This also contributed to our user stories.
Looking at the Trello card above this shows a pivotal piece of the project I contributed to. When looking through the deployed site we discovered that many of the incidences on the map would show a large number of incidences clustered together, but upon zooming in this number would disappear and we would be left with 1 incident. We had a hunch that this might be due to duplicate data being sourced and this was determined later to be true.
The Speed Bumps
Every project is subject to challenges that you have to face as a team and individually. Each challenge our team faced and I faced by myself allowed for growth and a better understanding of our product and codebase. I think the biggest struggle our team faced collectively was really understanding what our code based was doing. Being given legacy code with not much other than a Readme to guide your way can be intimidating. Each of us took most of our first week on this project to understand each file and what it was doing.
During this project, I worked as the back-end developer and while looking through my repo, I discovered a couple of key challenges about the project.
- There was a lot of dead code
- This repo was not hooked up to a DS API or connected to the front end
Dead code in a project is a problem because when other developers continue on the work you have done it can lead to things appearing to be working when they are not. This is precisely how I discovered this problem. When exploring all the endpoints that were in the repo I noticed a whole section wasn’t working. Additionally, the routes and models were not hooked up to a schema. This whole process of trying to make this work took almost two days, without success. There came a time to meet with our team lead and it was discovered these files weren’t even needed as this feature was not apart of the project anymore. I had to delete 4 files of dead code. Deleting that gave the project cohesion moving forward, because future developers would not try to get broken/not used code working.
When looking through the repo it was also discovered that nothing was hooked up. There was a bunch of seed data that even if it was hooked up would be inaccurate because it had a large amount of duplicate data. This is a problem because it can weaken the credibility of our map. Specifically, on the deployed site, we saw the Portland, OR area with 400+ incidences but this is due to duplicate data when there was actually only a handful of reported incidences there.
This problem was solved by fixing our /fetchfromds endpoint to fetch data from our DS API and create new incidences in our back-end database.
Due to this change, it allowed for this end-point /showallincidents to become functional. After this change was made our back-end was able to be deployed and we finally were able to give an endpoint to our front-end team so they would display relevant data to the user.
The Continuance
As we end 4 short weeks, we reached the end of our time with this project. As a team, we were proud of the strides we made knowing as more teams work on this project we helped move it that much closer to the end goal. Currently, we accomplished the biggest task of hooking up our front-end to fetch data from the back-end and DS team. This ensures that users are getting accurate information when viewing our map.
Looking forward as a team we discussed some future features of this project. Those were, using the prediction model the DS team created and the ability for a user to report an incidence of police violence on our site and see it represented on the map. Each of these has it’s own challenges. The main challenge we see with a self-report feature is there needs to be a monitoring system in place to verify the reports people create to remain a credible source for information.
During this process I have learned a lot about working in the face of ambiguity. For a lot of this project, we weren’t given a lot to go off of and we had to make some crucial decisions individually and as a team. The most important thing I learned is that it’s ok to be confused at first because it helps you find a clear way forward.
