HW2: Responses

All three of these articles deal with the concerns of managing software engineering projects and producing healthy, scalable code, as well as practices to become an efficient software engineer. Many of the complications that are innate in software development that are detailed by Brooks and Neville-Neil appear to be somewhat addressed in “Google Code Repo” by Potvin and Levenberg in their detailing of Google’s use of a single, monolithic repository.

In “No Silver Bullet”, Brooks asserts that conceiving, describing, and testing software is far harder than any other human construct because the scaling of code is an increase in the number of different components and not simply a repetition of existing components. Brooks also mentions that lack of communication among team members is a problem inherent in any software engineering project. Google’s use of one vast repository that all employees have access to virtually eliminates any barriers that one team or individual may have regarding communication with any other person. As a result, the codebase is able to scale naturally. Additionally, because the entirety of the code is in one repository, teams are able to depend on other teams’ code without miscommunication about where an authoritative version of a file is located.

In “Kode Vicious”, Neville-Neil promotes diligently working and communicating with team members to as not to delay any software when the times comes to merge with other work, He emphasizes that not the most difficult part of maintaining code is properly integrating with the head of a development tree because of a lack of periodic merging. His remedy for this issue is to use the scientific method to hypothesize how to fix an error or bug in order to make code able to merge properly. However, Google offers different solution to the issue of incompatible code being produced due to lack of team communication. This issue is dealt with inherently by Google’s use of a single repository, as all commits from any software engineer will be added to one codebase without the need for merging in the first place, thus preventing software engineers from experiencing the “suffering” of code merging in the first place.

According to Potvin and Levenberg, communication among teams is easier when using a single repository because having access to an entire codebase encourages code reuse and sharing and has allowed Google to develop several tools for managing its’ codebase, such as Piper for version control and Rosie for breaking patches into small parts and individually testing them. Additionally, because the code base is all in one location, the tools developed are able to be scaled with the code and allow software engineers to find relevant libraries and clean up code in a time efficient manner.

“No Silver Bullet” was published in 1987 and “Kode Vicious” in 2013, however, both articles address a lack of communication between software engineers as a key hindrance in the development of any software, as even after decades of progress made in the software industry, this problem persists. It does not seem possible to guarantee one hundred percent communication among teams in any profession, and there will most likely never be any one “silver bullet” to address every issue in producing efficient software, however, Google’s use of a single repository currently seems to be the most efficient solution.