In ICS 314 we worked in small groups (2 - 3 people) and we got to come up with the idea for our final website ourselves. Going into 414 I thought it would be similar, making a group and creating a project. It turns out that we were going to be making a project for someone else, the DOE.
The DOE wanted a new legislative tracker, their old one is on Lotus Notes and is very anti-user friendly. Using Meteor and react-bootstrap we were told to make a website that could keep track of legislative measures as they go through the DOE legislative process, I will go into further detail later.
The most important thing I have learned in ICS 414 is that the customer knows nothing about programming. Do not assume they know what is easy to code and what is impossible, there needs to be clear communication between programmer and customer in order to get a product that works for both sides, and is possible to create.
This also goes vice versa, as developers we didn’t know much about how their system works, but we have to know in order to make a good product. The most important thing to do is ask good questions.
Good questions are specific, carefully thought out, and usually have a specific answer
Good Question:
When it comes to the role of PIPE when measures come in, can all users see them, or is it up to PIPE to assign users/offices the measure for them to see the measure?
Bad questions are broad, rushed, and hard to answer
Bad Question:
What about the website do you want to change?
This question initially is good, but as you get into further conversations with the customer and question like this is useless.
With our questions done, it’s time to get to the project.
For our project, we made a Legislative Tracker for the DOE. To summarize the DOE has measures that advocate for changes. During DOE Hearings they decide whether or not a measure should pass. During Hearings, each measure has testimonies, written by offices who are assigned to the measure. These testimonies can be against or for the measure. Once a measure is assigned a hearing date the testimony process starts. For a testimony to get approved to be read during the hearing it has to go through many people:
Office Secretary → Testimony Writer → Office Approver → PIPE → Final Approver → Office Secretary
We made the website with these different roles and allowed testimonies to be created, sent along the workflow, and approved and printed all on the site. Besides that, other features we added were folders that users could put bills in, a calendar with hearing dates, the ability to see all measures, assign offices to measures, and many other Quality of Life functions.
“The Minions” was the name of our group, and it consisted of 8 members. This was a big change from 314 which I had 3 people in my group. Working with a larger group had its pros and cons. One of the pros is that working with a large group makes it easier to make larger projects. One of the cons was that sometimes there was a lapse in communication and the way one part of the website works doesn’t work with certain functionality. We handled these issues by using issue-driven milestones on GitHub where everyone can see what everyone else is working on. This was my first time doing a long project with a group this big and it was a great time!
In conclusion, ICS 414 had me use the core concepts I learned in ICS 314 and apply them to a longer project. It was a taste of what it is like to work with a customer and what it is really like to be a software engineer. Definitely would recommend this class to any ICS students in the program.