Summary Reflection

Robert Young

English 250

Section PN

Article Summary Reflection

I think I rushed this assignment way more that I did with my other assignments. I could keep telling myself that I had plenty of time to do it, since I had a week and a half. When it finally came down to that last day, and I still didn’t have it done, I panicked. I was up until three in the morning trying to finish it. I only ended up getting four hours of sleep Thursday night because of it. Then I got to class on Friday and found out that it wasn’t due till midnight, and I was like “screw it, I’m taking a nap.” I wrote this reflection first so I wouldn’t forget all of the points I was going to make.

Honestly, I don’t expect that my grade on this will be very good, and I know that isn’t very good because it is one of the very few graded assignments in the class. I think that is because there were multiple definitions of summary going around in my head as I was trying to write it, and it turned out almost exactly like the abstract in the actual article, except longer. The only difference is, I think I went into a little more depth than the abstract, but didn’t nearly get to the level of detail as the article.

The thing that was confusing me is I kept asking myself “Why am I writing a summary if I can just look at the abstract again?” and I kept thinking about the article we were to read about writing summaries, and how we were supposed to tie the article to our opinion. Then I kept thinking I heard you say in class that you didn’t want our opinions in our summaries, so this is what I ended up with. I have a general overview of the entire article, while going a little more in-depth than the abstract of the article itself.

Most of my thought pieces I did in about fifteen minutes. This summary took me like five hours (from 10 Thursday night to 3 Friday morning).

On the plus side, I did learn quite a few things about communication in Software Engineering: when working in groups, it is absolutely essential that everyone communicates. There are projects that need coordinated, people that need to work together to do certain things, people that need to make sure they are meeting certain specifications, etc. How well a team communicates may have a very strong influence on how good the final product is. Some of the practices discussed in this article help to increase efficiency in both communication and in development.

That is all. Ta Ta.

Article Summary

Robert Young

English 250

Section PN

This study is about the effect that Agile Development Practices have on communication between a development team and other people, like the consumer or management. Basically Agile Development Practices were designed so that a team of Software Engineers can work more efficiently. There are several different methods to do this, and the ones they focus on in this particular study are the XP (eXtreme Programming) and SCRUM (I couldn’t find what this acronym stood for, sorry). In Extreme Programming, the development team develops their program incrementally, with periodic “releases” that add features, and over time, all of these features add up to be an entire program. In SCRUM, the development team gets a set of requirements from the product owner to fulfil over the next month or less. The product owners then go over what all the development team has done, and sets new requirements that build off of the present program. I only gave the basic rundown, no specifics yet.

Communication is important in Software Engineering because it helps coordinate specific tasks that can be combined into one big thing. The balance is having enough time to communicate between your team, enough time to communicate with your customer, and enough time to actually code and work on the project. This study examines the effects of increased communication on the team level on the communication with the customers. There are two variables: internal communication, which focuses on communication between members of the development team; and external communication, which focuses on communication with people other than the development team.

The data they used for their analyses was obtained in a variety of ways: interviews, documentation, and direct observations. The documentation was typical of other software development projects. There were six interviews and several face-to-face discussions with project leaders. There were also visits to the space in which they worked.

The data was analyzed on an “in-case” basis. That means they took specific cases to analyze, instead of the entire population as a whole. This is because there is so much variety in software development teams and environments that it would be unacceptable to compare results with each other.

The Results in terms of Internal Communication:

In an open office space, there was less need for documentation and everybody knew what was going on. Daily meetings were a good way to keep the developers, project leaders, and sometimes the customers aware of where the project was in development. The task board allowed everyone to see what needed to be done very quickly. Planning meetings helped define the goals for the development cycles. Development cycle reviews helped make sure they were on track. Programming in groups of 2 (pair programming) is an efficient way to review code, but not good for days on end.

However, in project 1, some of the documents weren’t properly organized, which made figuring out which features were already implemented difficult, and the development cycle planning meetings were too short to fully cover all of the features and requirements. Some of the developers felt that the requirements weren’t descriptive enough. The focus of the project as a whole wasn’t really there. Some features got implemented that weren’t really needed. Some of the developers really liked the open office space, others really didn’t, and that affected the concentration of everybody. Project 2 actually disbanded the open office space, then went back to it because their User Interface needed better collaboration.

The results in terms of External Communication:

Iteration reviews and status reports helped increase the visibility of short term goals and requirements, and development cycle planning helped with short-term focus.

However, the developers felt that the development cycle meetings with the customers were not long enough to discuss the requirements, especially when the software became more complex.

Overall, Agile development practices mostly benefit communication. Cycle Development planning meetings and incremental development helped the development team to not take off more than they could chew in one cycle. Daily meetings kept everybody up-to-date, along with the task board. The open office space made it easier to collaborate. Unfortunately, there were some drawbacks. Some viewed the open office space as distracting, incremental development made the developers lose sight of the grand plan, and the development cycle planning meetings weren’t really long enough to go in-depth about the requirements with the customers.

Abrahamsson, Pekka, et al. “The impact of agile practices on communication in software development.” Empircal Software Engineering, an international journal. 13.3 (2008): 303-337. Web. 13 Jan. 2014. http://link.springer.com.proxy.lib.iastate.edu/article/10.1007/s10664-008-9065-9/fulltext.html 

CEO ThingyMaBopper

Dear Everybody:

It has come to my attention that a consultant will be visiting our firm to assist with the debugging of Project FTW. The company she is from normally debugs physical objects, like go carts. However, she has expressed an interest in validating code for our project. I am sure each of you will get to know her very well over the next couple of months.

Now, she is here to learn, so if she asks questions, answer them kindly. Her voluntary participation is vital for Project FTW, so don’t be rude. Also, try to explain things that may seem complicated. She might not understand at first, but she is an extremely intelligent individual, and will be able to figure out almost anything.

She will need access to any design documents or project ideas that you may (or may not) have come up with.

I appreciate your cooperation, and value your continued participation in activities.

Robert Young

CEO

Systemificated Softwares, Incorporatified.

Embedding a Google Calendar on a Blog

1. Log into Google calendar at calendar.google.com.
2. Click on the gear in the upper right hand corner, then select "settings"
3. Click on "calendars"
4. Click on the name of the calendar you wish to share
5. Scroll down to "Embed this calendar"
6. To customize your calendar, click "Customize the color, size and other options," then copy the HTML at the top of the page
1. Otherwise, just copy the HTML provided
7. In Blogger, create a New post
8. In the upper left hand corner, click HTML
9. Paste your code
10. Publish. Your calendar will now be on your blog, and nobody should be able to edit it from there.

Making your calendar public (or else, nobody will be able to see it):

1. Complete Steps 1-4 above
2. Click the "Share this calendar" tab.
3. Check the "Share this calendar with others" checkbox
4. Check "Make this calendar public"

Anybody who sees it will NOT be able to make changes. You have to explicitly grant permission for others to edit your calendar.

I would have added that earlier, but I didn't know you had to actually share the calendar for other people to see it through embedding (if that makes sense).

How would you find out how writing works in your field?

I would probably ask somebody. I would ask a person in my field (My dad, for instance, who works at john deere developing software) how writing is useful, what you need it for, why you need it, and how often you have to write. Honestly, Software Engineering is a lot of writing. You write code, you write reports, you write memos to other team members. You write the documentation for your program so that the people that are supposed to use it can use it.

Scholarly Articles for Communication in Software Engineering

http://onlinelibrary.wiley.com.proxy.lib.iastate.edu/doi/10.1111/j.1360-0443.2010.03104.x/abstract

http://link.springer.com.proxy.lib.iastate.edu/article/10.1007/s10964-008-9390-8

http://www.sciencedirect.com.proxy.lib.iastate.edu/science/article/pii/S0001457510001995

http://link.springer.com.proxy.lib.iastate.edu/article/10.3758/s13423-011-0177-7

http://www.sciencedirect.com.proxy.lib.iastate.edu/science/article/pii/S0022395610003286

http://onlinelibrary.wiley.com.proxy.lib.iastate.edu/doi/10.1111/j.1469-8986.2009.00925.x/abstract

http://psycnet.apa.org/journals/bul/136/2/174.html

http://psycnet.apa.org/journals/bul/136/2/151.html

http://informahealthcare.com.proxy.lib.iastate.edu/doi/abs/10.3109/00952990.2010.491879

MLA Citations:

Padilla-Walker, Laura M., Larry J. Nelson, Jason S. Carroll, and Alexander C. Jensen. "More Than a Just a Game: Video Game and Internet Use During Emerging Adulthood." Journal of Youth and Adolescence  39.2 (2010): 103-13. Springer Link. Web. 23 Jan. 2014. doi: 10.1007/s10964-008-9390-8


Van Rooij, A. J., Schoenmakers, T. M., Vermulst, A. A., Van Den Eijnden, R. J.J.M. and Van De Mheen, D. (2011), Online video game addiction: identification of addicted adolescent gamers. Addiction, 106: 205–212. doi: 10.1111/j.1360-0443.2010.03104.x



I didn't know if we were actually supposed to do these or not, so I just did.

Thought Piece for "Reading Games: Strategies for Reading Scholarly Sources"

I couldn’t tell you how many times I have fallen asleep trying to read something for a class. Often, I fall asleep reading books that I really enjoy, too, even if it is mostly because I end up staying up till 3 or 4 in the morning reading them.

I wonder how many people went back and reread this with the principles presented in it in mind. It has all of the parts it said to look through: an introduction, section headings, and a conclusion. I know that I went back and went through the whole thing again. The first time I read it, I had no idea what it would be about. I was trying to make sense of it, and it didn’t work to well. When I finally got to the “Strategies for Rhetorical Reading” section it finally started to sink in, and that was only like half way through the article. After reading the whole thing, I was like, “You know, this probably applies to this article, too.” So I went back and looked at all of the major parts of it (the section headings, intro, and conclusion), and the whole article made more sense already. I looked at the section headings to see what was important. The section headings in this article: “The Title”, “The introduction”, “Section Headings”, and “Conclusion”. All of the most important things of the article. Of course, the body is important too, but if you are just trying to figure out what it is about, these things are what you would want to look at. Overall, this is actually a very good way of approaching reading. I will definitely be using this strategy more in the future.

One thing I didn’t know before I read this was that you are supposed to figure out what the intended audience for the article is. In retrospect, it is actually a really good idea. It doesn’t make sense to read an article from a scientific journal and expect it to be general-reader friendly. It has all of the technical details, all of the “how it works.” General readers tend to just care if it works at all, not how. Thus, they would be less interested in the how. And realizing that does some strange thing with the human psychology, and it becomes easier to understand after that. It’s crazy I know, but somehow it makes more sense.

The whole thing about scholarly articles not trying to draw you in kind of makes sense. Scholarly articles are there for those who need the bare facts. They need to find out what they are looking for, and find it fast. They don’t need the fluff that a lot of other sources put into their articles. Their purpose is to inform, and in great depth. To do that and keep it interesting would require an entire book, not just an article.