Homework #2 - 8/27

Responses for "No Silver Bullet", "Kode Vicious", and "Software Analytics: So What?":

     First of all, "No Silver Bullet" was probably my favorite article of the three because the author made his case in such a systematic and thorough fashion. He begins with talking about the growth and advancement of computer hardware in tandem with its reduction in cost during the past few decades and how the transistor along with other electronics and organizational methods made that progress possible. It was the one thing that solved all of the problems, a kind of "silver bullet" for the obstacles of growth at the time. He then points out that there is no such silver bullet for software development progress and likely will not be in the future. There are many reasons that he points out, but the main one that stuck with me was complexity. He says "Software entities are more complex for their size than perhaps any other human construct...". I always thought this was the case, somehow, but now seeing someone else point it out, and give reason why totally validates what I thought, sometimes, to be self-pity. The author has several other attributes of software that make it unlikely to see the same progress as hardware, such as there not being any good way to visualize your product, unlike anything made in the physical world, where you can have blueprints, measurements, and scale prototypes. He then goes on to talk about how the progress software development has seen is due to the solving of the "accidental difficulties". This includes the advent of the high-level programming language, saving time and increasing productivity by abstracting the language from the machine instructions. Of course, with most things in this article, there is a negative side to the subject, as the author points out the limits of the different strategies of increasing productivity.

     The amazing thing about this article is that in spite of all of these difficulties and the limits of the past breakthroughs, the author hold out hope for progress. He says that creating a kind of software development repository, where programmers can reuse code from other projects to apply to theirs. This kind of situation would require the collaboration of many companies and government departments to pitch in and add to the bank of code. While I do think this would greatly increase programmers' productivity, I don't see it happening for a while. To a degree, I'm glad though, because it would mean less programming jobs and probably reduced pay as well. Another strategy that the author points out would be to grow code instead of building it. This entails building small portions at a time to get them working and tested, then add to it incrementally, making sure each part is working as you go. I really like this idea, and am going to try and employ it as much as I can while coding, as it prevents you from doing a bunch of coding and having to track down the bug when finally testing it. Finally, the author says that we must find a way to turn any software designer into a great software designer, as the difference between the two is a big one, and if it were possible to make all designers great ones, we would significantly increase our overall productivity. He points out that great programmers and managers are equally rare, but, amusingly, he doesn't see companies spending as near as much effort in finding and cultivating great programmers.  I'm all for this one as well, it makes a lot of since to strive towards this goal. There may be no "silver bullet", but I agree with everything professor Brooks has presented in this essay and am looking forward to the bumpy road ahead. 

     Well, there's 500 words already....but we'll continue on. The next article, "Kode Vicious", is more of an editorial response to readers' questions. The author points out some great practices to use while programming, though. The first is about knowing when to just quit and instead do something else, which may be any number of things. I have run into this feeling several times over my scholastic career, and the most common thing I do is to start fresh, or reconsider my approach to the problem. Hopefully, after taking this course, I will have become better at taking the right approach from the start. The other programming practice the author points out is to use the scientific method while fixing bugs. Document each bug, give a theory of why you think it is happening, possible solutions, and whether or not the theory was proved, or disproved after the fix was applied. While this sounds like a great idea to use when programming in the workforce, I don't see myself using it as a student. The programs we write are usually too small or simple to require such meticulous practices. I just hope I can remember and utilize it after I graduate.

     The final article, "Software Analytics: So What?", seems a little more abstracted than the others and is a little harder to grasp. From what I understand, software analytics is basically the process of mining software development data, either past or present, to improve the quality of the software currently being developed. This means things like looking at patterns in old projects to see obstacles they encountered and how they solved them. This is very similar to one of the proposed solutions from the first article on how to increase software development productivity, a sort of global repository on solutions to common problems. One of the easier points to understand that the article makes is that if you have a commonly asked question, you should build a toolkit to address it; If you have an infrequent question, you should deploy a data scientist before deploying any toolkit. I will be interested to see what software analytics evolves into and how it will aid software development in the future.