Beyond the basics
04 May 2023
What’s next?
Software engineering principles can be applied to numerous different cases within the programming world. Currently I’ve only been introduced to certain principles and how they apply to web development, but what other applications can these ideas have? Some of the most vital and fundamental programming concepts I’ve learned over the past few months have been coding standards and agile project management. Through this essay I’ll discuss different software applications that I see concerning these specific principles beyond web application development.
Programming grammar
One of the principles that I found valuable this past semester was coding standards. Coding standards are a set of rules and guidelines for programming languages and libraries. These formatting standards can improve code readability, enforce a uniform look and feel for code, and ensure a high level of code quality. Also, following coding standards diminishes the potential for errors by detecting common mistakes associated with certain languages and libraries. To make sure coding standards are present in your code, you need to find a tool to use, implement it in your development environment, and fix the mistakes that are highlighted.
Over the past few months, ESLint has been my coding standards enforcer. This tool was used a lot when developing web applications for my projects. It helped to ensure that all my team members’ code had a uniform feel and prevented any broken code from being pushed to the main branch on GitHub. Beyond web applications, I can see myself using coding standards in all my future programming projects. Especially when it comes to projects with numerous people pushing and pulling from branches and sharing code, having a set of rules and guidelines will help immensely in preventing conflicts. Having the team agree on certain coding standards at the beginning of a project will probably be the best course of action. If the code that is being produced by all team members is uniform, the project will have a complete feel. Additionally, code with errors will be less likely to make its way into the project’s main code.
Going with the flow
Another software engineering principle used over the past semester has been agile project management. This type of project management has a ‘‘go with the flow’’ feel to it. Throughout the project’s lifecycle, steps are executed incrementally with continuous and adaptive planning and testing. Tasks are always being worked on by team members, everyone knows what task to do next, and the project’s status is visible to the whole team. Specifically in the project I just worked on, we used a type of agile project management called issue driven project management (IDPM). In this method, work is divided into tasks that take no longer than three days, tasks are converted into issues, and those issues each have a single owner. All the issues are then divided into milestones that have due dates and belong to their own project boards. At all times, each team member has at least one issue that they are in charge of completing. The milestones of a project also represent different phases. Each milestone has a due date and only one is active at a time. Team members work on issues that are in the milestone that is currently active.
Other than implementing it in web application development, I can see myself using adaptive project management in most of the software engineering projects that I will work on in the future. I really like the fluidity and flexibility of the planning that is associated with this style of project management. If I’m part of the leadership team for a project, agile project management will be my desired method of execution. Projects and their tasks always grow and change, so using an adaptive method of management will be helpful to progress the project while also giving room for flexibility. Specifically, for IDPM, I can see myself using that method for projects with smaller teams. Having tasks up for grabs for whoever completes their current task is a great method to progress the project and make sure everyone is working on something, but with a larger team that management style may become complicated. There could be confusion with the assignments of tasks which could cause chaos if there isn’t someone to delegate who should execute which task. Also, if there isn’t a clear and common vision for a project with a large team, the issues created could potentially not progress the project. Therefore, I think IDPM is a great method of project management, but only for smaller teams.