HW 2

The articles No Silver Bullet, Kode Vicious, Google Code Repo share a common concern with how software should be organized, and the procedures taken that could be beneficial to software engineering, and therefore also produce an excellent software engineer.

The article No Silver Bullet makes a comparison between werewolf’s and software engineering. The concern here is how at any single moment the program could break. It discusses how complex software engineering can be to fully grasp, and mentions no real solutions exist to on how to fix this lack of complete understanding or in other words there is no silver bullet to end the beast. The article does state however that working with experienced people leads to furthering one’s own experience.

The article Google Code Repo discusses their monolithic repository, and how other resources have been utilized to make their repository possible. The majority of Google’s software engineers are running off the same repository. This done by using piper and CitC to store the code that is written into the repository. A plus to using this method is that engineers do not need to perform extensive testing on their project while it is being built as using one repository keeps everyone up to date. This method is also useful for the re-use of code. Multiple teams could share code in order to accomplish a different set of tasks. The article the ends with a discussion of why their model works, which it attests to their open work environment. Stressing that working in a stress filled environment can be just as detrimental as bad organization or one’s own personal skill.

Unlike the No Silver Bullet article, The Kode Vicious article provides  more tangible insight onto how to become an excellent software engineer. The article provides answers to two questions that might be common to software engineers. The article is an anecdotal account of the author’s experience in what not keeping well organized code can do. The first thing the author mentions is that an engineer can ease the difficulty of their task by merging branches often so that there is a less need to pick through your code later searching for that line you are looking for. The author also talks about the importance in keeping every member of your team informed on the task at hand and future task as well. This is to ensure cohesiveness of the team, and allows the code from different parts of the team to merge together more efficiently. It then discusses a strategy of documentation that comparable to the scientific method. Utilizing this strategy often leads to well documented code that offers and easy readability to anyone who tasked with working on the code written.

These three articles all provide us with methods that help produce more organized, thought-out code from sources such as a personal story from an experience programmer, a large company such as Google, and addressing fixes to the problems that arise