Brooks highlights many reasons why there is not a magical solution that will make software engineering less cumbersome:
• The very nature of abstraction can strip an entity of its essence if it is oversimplified.
• The industry innately models those things that continually change which causes the product/software to do so as well.
• With programs and requirements continually growing and with the addition of many constituents working on a project, being able.
to accrately visualize and model the software in a cohesive agreed upon manner is challenging.
In the readings from “Kode Vicious” and “Google Code Repo” we read 1st hand testimony and 3rd hand accounts that highlight some of Brooks concerns that are taking place in todays industry. Although the overall tone of Brooks makes software engineering tasks seem insurmountable he believes the most effective way to de-complicate software modeling is to reuse code and build onto what has already been established.
“Kode Vicious” highlights the concern of what is truly the best way to model a problem and approach a task. We see here that what Brooks describes as the ability to visualize a process in a cohesive manner is not a straightforward process. With many “eyes” trying to tackle a problem, it comes with many ideas in what approach works best to complete that problem. We see that individuals members of a team may have an approach they think is best while other members working on the project such as upper management may have differing methodologies. This supports the idea from Brooks that the number of constituents working on a task can correlate to the complexity in how to visualize and complete a task. George Neville-Neil (author of Kode Vicious) believes that the best way to approach a task is by a method that can be found in other sciences… the Scientific Method. Through this approach one is able to document and resolve problems via a process that allows for others and oneself to accurately identify and mimic the solution.
"Google Code Repo" explains how Google was able to accomplish its massive repository called Piper, and the plights they face and faced when designing the repository. Many of those plights where ones that Brooks highlighted as challenges in designing software, the most prominent being that of visualization. How to seemingly allow many different workers to work on a project simultaneously in a synchronized manner that does not corrupt the code. In short, how to keep everybody on the same page. Google was able to accomplish this by a method called Trunk-based development. With this approach, users work with one consistent view of the codebase where source code updates are in a way enumerated and sorted or “cherry-picked’ for the best results. With the Trunk-based approach, Google has essentially synchronized the work of thousands of their developers. They did this by creating a process of unified versioning, reusing code, and having clear visualization, a ‘best-fit” solution to software modeling that Brooks proposed in the Silver Bullet.
We see throughout these articles why software engineering can be cumbersome, but challenging does not equate to impossible. Brooks stated reasons why software modeling is challenging and he suggested methods to best accommodate for them. In Kode Vicious and Google Code Repo we get first hand accounts of those challenges, but we also receive testimony to what works and how it was accomplished, all in which supports Brooks ideologies to the approach of software engineering.
No comments:
Post a Comment