This article is about the “What is Software Engineering?” chapter in the Software Engineering at Google book. The article goes into more detail regarding the differences between programming and software engineering and talks about important considerations when working as a software engineer. Software engineers must concern themselves with the longevity of the program they work hard to maintain. Software engineers must aim to work as a team, as these are not single person projects due to their substantial scale and scope.
Depending on the longevity of a piece of software, the user base and developers may witness various modifications to their environment, such as dependencies or tooling being updated. As longevity increases, the responsibility of the software engineers to keep their code base up to date is equally important across the lifespan of their software; however, with these changes often brings resistance. For this reason, adjustment is an important quality to possess as a software engineer. That said, it remains important to be proactive through this process, because, if something is wrong with the software, and no action is taken, this may cause even more problems in the future. Being complacent and discerning are two distinct attitudes that can often be confused in this process. A discerning attitude in the adoption of new software should be applied with Hyrum’s Law, which makes the following assertion:
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. need to assume that every part of the program will be used by someone. (Credit: https://www.hyrumslaw.com/)
This means that, once a feature is published, removing that feature now presents a very large ship to steer. Software engineers need to discuss features with scrutiny, acknowledging the pros and cons of those features before moving forward with decisions. Our team member Jaclyn Pham has described some factors that come into play for software engineering teams:
- Time Dimension: Engineers must not only create code but also maintain it over time. Therefore, the role of a software engineer surpasses the role of a programmer, looking beyond the immediate problems and solutions.
- Scale and Growth: Software engineering acknowledges the vast scales of modern applications and technology. The growth and scalability of software systems are integral considerations that go beyond the scope of only programming.
- Trade-offs: Engineers must weigh various factors and costs, such as financial, resource, engineering effort, and make informed decisions.
One must also acknowledge that they may not be able to do something they wish; trade-offs may have to be made. Being able to make these decisions is what can define a good software engineer. The project needs to be scaled appropriately as factors change: the amount of people working on it, the amount of time available for maintenance, and what is possible with the tools being used. If this isn’t done one may find themself working on something for long periods of time that ultimately leads to minimal or no gain compared to the effort and time it took to implement. Thus, making these decisions is crucial to ensuring that a software engineering team accomplishes tasks both effectively and efficiently.
As stated before, it is important to understand that software engineering is not single person operation; it require people to communicate, be organized, and be informed of the direction of the project. If people aren’t on the same page then individuals may be found doing redundant, irrelevant work or no work. This hinders progress in a project. It is important to be critical of the systems and rules in place, as they may need to change, depending on the situation. Good decisions are never put in place on the basis of “because I said so.” A team without organization or forms of criticism and adjustment put in place is not a successful team, so it is important to be open in communicating opinions or concerns with colleagues.
While as a team we have made improvements in organization and communication, there is still a long way to go. As many people seem to not be on the same page and are still having problems running Chasten, it makes it very hard for them to contribute. This has caused us to miss deadlines as a team. Many people are unaware of what is going on and what they are supposed to be doing. Some people in our team do not even know how to run the program on which they are currently working. This is a result of people being uninformed. This isn’t completely a result of poor communication, as many of our tools have corresponding documentation, but if someone is falling behind, then we as a team all fall behind. Therefore, it is our responsibility to help them so they can succeed, resulting in collective success.
What Can We Do?
In our team, we need to “step up” and take responsibility for each other’s success and failures. We have yet to fully grasp the importance of teamwork and communication. This has significantly stunted our progress on Chasten. Additionally, we need to develop a schedule for each class meeting we have. We often spend our entire time discussing action items that should be worked on outside of the meeting. In summary, we need to take the following steps:
- Help each other
- Take responsibility as a unit not an individual
- Seek to self organize