Monday, August 26, 2013

CS 362 Homework 2

For this post, I will be reflecting on three articles that are pertinent to software engineering

No Silver Bullet (Frederick P. Brooks, Jr.)
There is no silver bullet for software. There does not exist some easy way to tackle all of the issues one faces whenever building software. You will not ever look at a piece of software and exclaim "THIS IS BRILLIANT! IT'S PERFECT!" That just doesn't happen. Even if your software was "perfect" you would still find ways to add features, speed up algorithms, add code readability, etc. On top of this, maybe you need to add a way for your software to integrate with someone else's software. Now your issue has expanded to include the issues of that other person. The bottom line is: there is always something you can add to software to make it better, but let's forget about that fantasy of perfect software and let's view this as realists. As part of a software team you have to do more than just write code. You have to meet with project managers, team members, and perhaps even developers working on a different part of the software (such as people working on the frontend to a program). This introduces all kinds of problems into the software development process. For example, the client for whom you are developing  software may not have been clear about something he/she wanted in the software, leading to software lacking features. This reaffirms the importance of the software development process of requirements elicitation. There needs to be a great degree of clarity of what you are doing. Considering all things, we will never find a silver bullet for software engineering, but we can create systematic methods for minimizing the daunting, painful nature with which software comes bundled. These methods include automatic code generation, graphical programming, artificial intelligence, object-oriented programming, and many others.

Kode Vicious (George V. Neville-Neil)
This article really hit home for me. The past two summers I have become familiar with using Github and Bitbucket in order to utilize version control for my outside projects. This past summer I was working with another person and we would sync to Bitbucket multiple times a day. You do get into entanglements sometimes, though so you may not sync your files for multiple days. I always hold my breath whenever I hit "local merge" at times like that because manually merging files is a major pain and git-merge software is not exactly the simplest thing. I resolved my issue that time by cloning the entire repository again just to avoid the disgusting nature of merging. I am at the point now where if I have not merged with someone working on the same branch as me in a short amount of time, then I make sure that I get that work merged. Aside from that headache, I would just like to put it out there that version control programs are amazing, provided you are not cherry-picking. Additionally, the article goes into documenting bug fixes and testability. It is never enough to just say, "Oh, I fixed that bug. I know it works." How did you fix it? Where is that code? What test cases did you use? These and many other questions can be posed to someone who simply says, "I know it works. I mean, I did it." By documenting all of these things you can avoid redundancy in the future and work more quickly, effectively, and efficiently. Bugs are bugs for a reason. If you swat one of them, then you better let everyone know how, when, where, and everything else about it.

Software Analytics (Tim Menzies & Thomas Zimmermann)
This article subliminally was whispering "big data" and "data science" into each of my ears before it even reached any depth. Data is the heart of analytics, though, so that makes sense. At one point this article attempted to detail everything for which analytics can be used. I thought this was hilarious because you could so much more easily make a list of what you could not do with analytics. No matter what field you are in analytics is of a dire, vital and growing importance and significance. Bioinformaticians attack their genetic data with their algorithms and analytics, through methods like dynamic programming. Some stock market analysts tackle their investing by running predictive analytics, with algorithms such as support vector machines and smoothing techniques, on relevant stock data. I will stop detailing now because, otherwise, this blog would never end. There is much more to analytics than analyzing data, though. How do you get this data? The answer is simple: share. The computer science community is probably one of the most open academic communities out there and that is part of what makes software analytics so fruitful. In addition to sharing data, the sharing of novel algorithms is crucial. Say you figured out a way to improve a classification algorithm, or maybe you just found an algorithm that predicts better in most or all respects, then you should present that to the community. Just think quid pro quo. More data, more algorithms, less problems.

Music listened to while blogging: OneRepublic & Kanye West

No comments:

Post a Comment