As this semester is coming to a close, I have found that my definition and perspective on software engineering has changed significantly since the first day of class. Coming into ICS 314 Software Engineering, I was sort of under the conception of software engineering as just designing website. And while that is of course still true, I have discovered that there is so much more to this experience than just making a website nice and functional.
This is a topic I already wrote about this semester, but I really feel it is one of the most important and impactful aspects of software engineering and coding in general. Coding standards are essentially a style of coding that is standardized in classes or in a certain discipline of computer science. It is used to make code have better readability, organization, and overall create better habits.
Coding standards in software engineering are important because of how collaborative software engineering is. While people can definitely tackle a big individual project, the most creative and innovating projects will probably be made by a team of developers. As there are so many people, each with their own quirks and individual preferences in coding, it can be hard to work off or add to other people’s work when you can’t understand what the code is doing or follow along. Having the group follow coding standards here solves this issue! It makes group work in coding flow much smoother and easier and can improve efficiency and difficulties already present when trying to build a website.
Outside of software engineering coding standards definitely also has a huge place in computer science. In any environment where collaboration and teamwork is necessary, so are coding standards. The ability to have enhanced readability across people and even possibly teams is irreplaceable for efficiency’s sake and something that will only benefit a project.
For the final project in class this semester groups implemented Issue Driven Project Management (IDPM) as a way of organzing and managing the work that needed to be done. IDPM guidelines mandate that groups meet 2 times a week minimum to talk abotu project issues and progress, have 72 hour max tasks, document each task as a Github issue, do the work in the for each task in specified branch, name branches based off of the issue number (isue-xx), use milestones to organize tasks every two weeks, in the TODO column have at least one active issue per team member, and have Github project board for each milestone. A milestone is essentially a way to group tasks in subgroups so that there is not only one big project board.
I found this style of management to enforce a very productive and non-procrastinating work pace. Spacing out milestones and publishing tasks to a board where all team members can monitor status and tasks motivates people to get their work done as to keep up with everyone else. Milestones especially ensure that no one is waiting until the night before the deadline to finish the entire project, instead having smaller goals along the way that will culminate in the end. I also think that the issue and branch system is easy to follow and implement. Doing each task in a branch makes sure that no changes made are going to immediately break the program in main, instead giving members the opportunity to fix all bugs and errors in their own space before sharing it with the group.
For uses outside of software engineering, I think that IDPM can definitely be used for any kind of team project. Anything where tasks are divided up between group members and the deadline might be far into the future and entice people to make early progress could benefit from using IDPM.
Many aspects of software engineering, especially those dedicated to improving and making teamwork consistent and efficient, can be applied outside of the discipline. Group work and learning how to manage time and progress is not restricted to just software engineering or even just computer science. These concepts can be applied across subjects and will prove useful in many other areas of work.