Billy Alfano CSC 4700 21 January 2013 No Silver Bullet One thing that I found to be very interesting about

the article was how applicable it was to modern day computing and practices. Even though the article was written around 25 years ago, many of the problems that faced software engineers still exist today. The author gives many examples of false predictions for the future that were unreasonable then and still are today. These include artificial intelligence surpassing human abilities, and automatic programming. Additionally he talks about the promising future of object-oriented languages. One thing that I feel is very relevant is his ideas about growing software rather than building it. I am not really sure how software construction was taught at the time, but it seems out of place to me that large software would be expected to be fully constructed in one fell swoop. It is better to create working portions of programs rather than try to build the whole thing first and fix the many bugs as a consequence. For larger programs, there are typically many components that are interconnected and work together. It is important to be able to test each of these components first before implementation into the whole and as such you can grow the overall piece of software. I know even from many simpler projects I have completed in classes that trying to fix the smallest bug since it takes a lot of time to fix maybe a typo or a logic error. Having a working program no matter what stage is reassuring because you know that if something goes wrong you can always revert back to the previous version in order to restart. An aspect of the article which I felt was not very clear was the portrayal of diagramming a program as helpful. I felt that this was an overgeneralization and that flow charts can be very

useful in getting down the important elements and ideas of a piece of software in order to have a starting direction. The author specifically said that he felt that the coding part of software engineering was not the difficult part but rather the planning for execution. I feel that either the software development environment was very different 25 years ago or else diagramming a piece of software before beginning construction (or growth) is being misrepresented as negative. It goes along with growing the individual components of the software in that there needs to be some organized way to show how the components work together.