HW2: Response

Linked to: Steven Fraser, Dennis Mancl, "No Silver Bullet: Software Engineering Reloaded", IEEE Software, vol.25, no. 1, pp. 91-94, January/February 2008, doi:10.1109/MS.2008.14Article written 20 years after Brooks's - IEEE panel discussin…

Linked to: Steven Fraser, Dennis Mancl, "No Silver Bullet: Software Engineering Reloaded", IEEE Software, vol.25, no. 1, pp. 91-94, January/February 2008, doi:10.1109/MS.2008.14

Article written 20 years after Brooks's - IEEE panel discussing the advancement in software development since the time of the original "No Silver Bullet".

A common theme between Brooks’s “No Silver Bullet”, Neville-Neil’s “Kode Vicious”, and Potvin and Levenberg’s “Why Google Stores Billions of Lines of Code in a Single Repository” is that they argue for the benefits of starting small and growing incrementally over time with regards to software and its development. All authors also advocate the importance of having a history of previous versions of the software, where, by making small commits at a time, the software’s integrity is maintained and, if something were to go wrong, it is easy to recover older versions. Neville-Neil claims that all code versions should be stored, “backed up, in some version-controlled way” (Neville-Neil, 33). His argument is corroborated by the “Google Repo” article where the authors explain at length the many advantages to vigilantly maintaining a monolithic repository such as Google, which stores a history of code versions and also makes it possible for a worldwide team of developers to collectively work on a single code source. 

Brooks’s insight adds to this by praising the concept of growing, not building, software - he advises that developers start small and first have a working base, then add to this to avoid problems of over-complication and possibly missing the entire point of a software’s purpose. He, like Neville-Neil, believes in the merits of science, and argues that software developers should look for inspiration amongst nature’s complexities. One such construct to admire is the brain:

“The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built” (Brooks, 18).

He advocates “top-down design, for it is a top-down growing of the software” (Brooks, 18). In saying this, his argument aligns with Google’s approach to developing and improving their code-base. All authors are in agreement that well-designed, maintainable code that adapts to the user or client’s needs is grown from a single base source, edited in small batches, tested, and merged to the master source.

These readings share the theme of “standing on the shoulders of Giants” (Isaac Newton) where they encourage not only growing software out of one main construct and merging any changes to the “head”, but also using a highly collaborative methodology for software development. In the “Google Repo” article, the authors argue that “The monolithic model of source code management is not for everyone. It is best suited for organizations like Google, with an open and collaborative culture” (Potvin and Levenberg, 87). Code sharing and reuse is widely encouraged in such an atmosphere, enabling developers to learn from each other and saving redundancies in problem-solving across the Google development environment. Similarly, Brooks’s argument calls for cultivation of great designers of software and advises that a step in the right direction would be to “provide opportunities for designers to interact with and stimulate each other” (Brooks, 18). He argues for the collaboration of creative minds in order to design software that serves as a step in the direction of finding the “Silver Bullet” for hideously gnarled software architecture. The authors collectively make an argument for not just implementing unstable quick fixes for software that has already gone monstrously wrong, but systematically address the problems that lurk below badly designed software architecture.