Web and Beyond
08 May 2023
As ICS 314 comes to a close, I find myself knowing a lot more about software engineering than I did a few months prior. However, amongst the myriad of important topics we covered this semester, two in particular stuck with me the most: the concept of issue driven project management, and the ethics of software engineering.
Issuing Issues
What is issue driven project management? For starters, it belongs to a broader category of ways to approach projects: agile project management. Contrasted to a traditional project setup where a concrete goal is set up with clearly predefined tasks to accomplish, agile project management offers a more flexible approach. You can break the project down into smaller, more manageable tasks, as well as adjust your approach at any part in the process.
Issue driven project management uses this flexibility to break down projects into smaller “issues,” which were implemented via GitHub issues in our final project. Each of these issues were done in separate branches. This offers the benefit of collaboration between team members without accidentally overwriting each other’s work simultaneously.
Think of it like going grocery shopping and ticking off things from your list. If you remember that you needed to buy eggs and forgot to write it on the list, you could always make a new checkbox on the spot. Or, if you realize the pasta you’re making for dinner tonight needs more ingredients than you previously thought, you can always add that to the list as well. The same goes for this style of project management.
Additionally, every few days, team members should meet up to discuss what they’ve accomplished or what problems they’ve encountered so far.
Of course, since this is just a general framework for any kind of project, it’s not just limited for use in web applications. Other software can easily be broken down into smaller parts for others to work on and achieve a successful result. Now that I’ve gotten over the learning curve of the GitHub branch system, I can see myself using this work style in other software engineering projects in the future. For example, it can be applied to tackling mobile applications in a similar fashion.
The Right Job for the Man
Another key takeaway from learning about software engineering is the ethics of the project in context. The professor reminded us many times over the course of the semester of being aware of the potential risks of your programs. Does your code do what you want it to do? Have you considered every possible edge case? Are there severe weaknesses in your program? And would you be comfortable working in an environment where if you make a mistake, you could impact hundreds or thousands of people?
In the case of a small test website like ours, bugs weren’t that big of a deal since our data was based off of sample data we inputted ourselves (i.e. example users and example recipes). However, on a larger scale this could turn disastrous. For example, if you were writing software for a top-secret government agency, if you mess up, you’ve potentially exposed key intelligence to malicious parties. Or, as my algorithms professor likes to say, if you write a program for a commercial airline and there’s a bug or uncovered edge case, it could crash the plane.
This is a sentiment that expands not just beyond web application, or even just software engineering in general—it’s an important responsibility in every job. Look at the false missile fiasco Hawai’i faced several years ago as an example; one mistake scared the entire island into thinking they were going to be blown up that same day. It never hurts to be cautious and thorough in inspecting your program for problems.
That being said, in terms of understanding the risks that come with your type of program, I’m not sure I’d be super comfortable handling such consequential tasks like government secrets or missile defense. However, even in smaller scale projects, it’s important to understand your applications can have great benefits… as well as great risks if used improperly.