 |
| George V. Neville-Neil |
George V. Neville-Neil is the author of Cherry-Picking and the Scientific Method.
A little about him: he is on the editorial board of ACM's Queue magazine and developed the column Kode Vicious- this is where our article comes from. He is the coauthor of the book entitled The Design and Implementation of The FreeBSD Operating System (It got 5 stars on amazon.com). He is a software engineer who currently builds systems for the global financial market.
 |
| "TomZ" |
Thomas Zimmerman is the coauthor of Software Analytics: So What?
Thomas Zimmerman is a researcher at Microsoft Research. He is also a Professor at the University of Calgary. His research revolves around programmer productivity by creating techniques and tools that focus on learning from past mistakes or successes.
 |
| Tim Menzies |
Tim Menzies is the coauthor of Software Analytics: So What?
Tim Menzies is a professor at WVU for various Computer Science courses. (He's actually on ratemyprofessor.com with an overall rating of 3.6). He was a former research chair for NASA before becoming a professor.
 |
| Frederick P. Brooks, Jr |
Frederick P. Brooks, Jr is the author of Essence and Accidents of Software Engineering.
Frederick P. Brooks, Jr became the manager for the development of the System/360 family of computers and the OS/360 software package for IBM. Apparently he coined the term "computer architecture". He also founded the Department of Computer Science at UNC Chapel Hill.
Article summaries/personal thoughts:
Summary/Thoughts:
In this column, readers write in and get their questions answered.
The first questions is about when to give up cherry-picking and merge. I wasn't really sure what cherry-picking meant (related to computer science) so after a quick google search, this gave a nice description: http://technosophos.com/content/git-cherry-picking-move-small-code-patches-across-branches. Because of my lack of experience, I'm not really clear on what the issue here is, but I'm assuming when you are moving commits piece by piece, there might be a few loose ends and it would be better to merge everything together as one cohesive piece. I'm sure I'll have a better grasp of this after hands on experience.
The second question is about fixing bugs and how to prove the corrections are correct. The author recommends approaching a problem by using the scientific method: write down your theory and develop hypothesis about problem. The key advice the author gives is to write this information down- he gives an example of his note taking system. This way in the future, it is easy to see what was tried, what worked, what didn't, etc. I liked his idea of keeping notes, something I will consider doing in the future.
Software Analytics: So What?
Summary/Thoughts:
This is one of two volumes on the subject of software analytics. The article first covers what software analytics is defined as. It specifies that analytics must be real time and actionable. It also talks about how software analytics today is focusing on sharing general methods to enable the discovery of local lessons. It has been realized that there is no global model, instead the focus is now on local models. This article also talks about general principles for analytics: how it's not about the hardware or software, but about the skilled data scientists. The last part of the article is dedicated to discussing the different and distinct kinds of analytics.
The distinction I found most interesting was internal vs external analytics and how privacy is a major issue, since altering data can damage the signal in that data, thus skewing results. My sister graduated from College of Charleston with a Data Science degree, so it was really fun reading and keeping her in mind. It will be interesting to see where software analytics take us in the future.
Essence and Accidents of Software Engineering
Summary/Thoughts:
This article goes through proposed bullet after proposed bullet to ultimately prove that there is no silver bullet that will improve productivity, reliability, or simplicity of technology or management technique in software engineering. But by proposing these bullets, there have been advances (some small/some large).
The idea of graphical programming is really interesting to me since I am a very visual person. Unfortunately no strides have been made in this subject and the author believes that no strides will ever be made for these reasons: the flowchart is useless as a design tool, the current screens are too small (the programmer would only be able to view a few things at once), and the author believes that software is very difficult to visualize. This article is about 26 years old, based on an advertisement on the last page, so I wanted to google and see if anything new has happened with graphical programming, but it doesn't look like anything has. I did find this blog: http://www.realsoftwareblog.com/2011/08/can-programming-language-be-completely.html. It did a great job of running through a list of visual programs that the author was familiar with that failed and why- really interesting and worth reading. This was a lengthy article, I got lost a few times, but stuck with it- really in depth and interesting read.
No comments:
Post a Comment