Rick Simons
CSCI-5200
Software Systems Engineering
Barrett
Homework Assignment 1
Review Only
9.5.01
Included in this brief essay by Mr. Brooks are several well thought out, and appropriate points. I am inclined to agree with him in many respects, and think that almost everyone would agree that software is unlike any other product or service on the commercial market today. Customer expectations of software are often inappropriate and absurd. I personally have to agree with Brooks citing the very nature of the product we engineer. I remember an illustration in my undergraduate Software Engineering class where a bridge was modified to have an off-ramp in the middle of the bridge leading to a local island. Obviously, other engineering disciplines are not required to re-invent or change their product to fit other needs as they arise. A bridge is a bridge; there are no off-ramps to nearby islands. However, what is generally considered 'good' software changes with the times and comes up with new features with free patches, purchasable upgrades, or product updates. It is not unthinkable that a customer request a word processing package, then half way thru the development cycle decides he also needs it to check his email.
Perhaps if one could create a concrete program, which did one thing and one thing only, and would not change, I would feel more comfortable with the software engineering process. Don't get me wrong, I feel the processes are valid, but the common notion of society towards software products is that they will change each quarter with new features. I feel that the software engineering process is the only thing that keeps it all flowing smoothly!
Brooks also talks later in the article about “buy versus build” as being one of the resolving issues of the software crisis, and one way I see that issue is most large application suites today have built in programmable expandability. Meaning a software engineering staff can add on to professional products produced by other companies. Microsoft suite products can be expanded by utilizing the VBA language, Macromedia products have their own proprietary Lingo language, and other large companies are doing the same type of product language within a product paradigm. This is one instance where professionally made, off the shelf software, can be manipulated by another company to build a product which fits their specific needs. In the article I think he is discussing the choice of purchasing tools, or even entire applications instead of creating them “in house”, but I think his description and ideals can be brought up to date with the examples I mentioned.
I did some research around the Internet for this article and found it popping up in various University Computer Science Department addresses. I didn’t know this publication or view was as popular or as widely used as it apparently is. Although I think this article is the opinion of Mr. Brooks, I think the points he makes are valid and should be considered when determining if Software Engineering is really an Engineering discipline at all. He contends that there is no one silver bullet fix for the state of Software Engineering today, however multiple new developments in technology or management techniques could combine to make said “silver bullet”. In my personal experience with software creation cycle models, I have found that in my real world instances it is more appropriate to use a hodgepodge of ideals from each model to create one that works for you in a specific project or development environment. I feel this article is a good read by anyone in the industry, or any Software Engineer student because some people look at new developments in the industry as godsends that are going to fix all of our problems. Brooks makes points for each recent development about why it is a good step in the right direction, but isn’t the answer to all our problems.
Finally, although Brooks has what apparently is a pessimistic outlook, his comments do lead back to my previous point about multiple developments being the possible answer. As we progress and learn more and more about software design and continually refine our development approaches, we will find that the seemingly different developments can be greater than the sum of their parts, and thus be the “silver bullet” answer we are questing for.