Terminal Summary - One Last Essay on Software Engineering
12 Dec 2019Here today, Gone tomorrow
It seems like it was yesterday that I officially started to learn about software engineering. My first experience in software engineering was back in 2017, when I worked in a team of three to develop a simple game of Snake using the C language. My next experience in software engineering was a year after, when I worked in a team of four to develop our own text-based adventure game using the C++ language. Then passes another year, to where I now sit here with a team four and an almost-complete web application, programmed with a HTML/CSS UI framework. What makes this experience much different from the other two experiences is that I learned about software engineering concepts. Instead of learning the structure of a language and being thrusted into making a product, this experience has taught me concepts about the software engineering mindset. Only after having learned this form of mindset did my team start to learn about javascript and start to work on our web application. There are many concepts that describe a software engineering mindset, but there are three concepts that stand out the most to me. Those are: coding standards, open source software development, and issue driven project management.
Coding Standards
Coding standards, as the name itself implies, is a set of rules to follow when programming. Following a coding standard results in improved code readability and avoids anti-patterns created by a programming language’s accepted syntax.
Coding standards is, in a way, analogous to Schrodinger’s cat. Schrodinger had a cat, and he conducted a thought experiment on it (not an actual experiment). In this thought experiment, he enclosed a cat in a box along with a radioactive atom that could kill the cat. He then came up with the idea that if he did not open the box to observe the cat, then the cat would be both alive and dead simultaneously. This idea of being in two opposite states at the same time can be applied to the coding standards. It does not matter if I write quality code, if the code does not observe a coding standard, then the code is both good and bad at the same time. Bad code should be avoided at all costs, so following a coding standard is the best thing programmers can do to achieve this, if nothing else.
Schrodinger’s Cat
Open Source Software Development
Open source software development means that the source code for a project is open to the public. This means that anyone can make changes to the code and publish it. This poses as a problem for the developers of the project since any inexperienced developer can break the project’s coding standards and ruin the quality of the source code. This poses as a problem for potential users because they will see a product of low quality and not use it. Thus, there are three directives in place that all open source programmers must obey, so that the products of open source projects have a significantly reduced chance of experiencing open source development problems.
Directive 1: The product must accomplish a useful task. Directive 2: The user can easily install and use the product. Directive 3: The product can easily be understood and enhanced by another developer.
Open Source Development
Issue Driven Project Management
With the programmer following coding standards and the three open source development directives, they are now capable of working in teams on a project. While there are many approaches as to how the team manages the project, our team went with an issue driven project management process. From the name, we see that this form of project management focuses on the issues surrounding the project. The basic idea of this process is to complete as much project issues as we can in a short time period. We divide the total amount of issues into 3-day long blocks and assign two of those blocks to each team member. Should a team member complete an issue block they will receive another issue block. It is highly encouraged for team members to meet up atleast twice a week to discuss their issue blocks and facilitate better coordination. We further organize the blocks into groups called milestones, which are 7-10 day time periods. At the end of every milestone we must have some form of progress done. To handle this form of project management we used the GitHub Project Board feature to create a project board, where the issue blocks and the milestones are managed.
With this last quote I leave this essay and school semester, more knowledgable in software engineering: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” (I don’t know who said this, but it is true enough for me to put it here)