Software Engineering Visual Communication: Basically, a flow chart.

Since Software Engineers don't use a heck of a lot of visual communication between other software engineers, flow charts and storyboards are all of the things that I could come up with for pictures. Storyboards are like a task list that is put up in a common area for all of the software engineers to see. A flow chart, like the one below, would be used to help other software engineers understand how a particular piece of code works.

This is an example of a flowchart that software engineers would use to help visualize a program. This particular example probably comes from a space shooter or water battle or something like that.

The audience: other software engineers who want to see how the code works or are developing the code themselves. Any other audience would look at this and go "What the heck is this?" If they looked at it a bit longer, they could easily figure out what it is for, but a lot of people won't.

The meaning: There is a lot of things that take place in a single frame of a game. This flowchart is what a program does every 1/60th of a second or so (depending on the speed of the computer). There are a lot of things on this flow chart, and since the first thing on it is "is frame end?" it suggests that this flowchart would execute every single frame of a game.

Everything's an Argument Ch 6 Thought Piece

Robert Young

English 250

Section PN

2/5/14

Everything’s an Argument: Chapter 6 Thought Piece

This chapter was all about rhetorical analyses. To be honest, I have done some of these before, and I didn’t think they were much fun, but after reading this chapter I can see how some people could have fun with it. It could almost be like a game, making arguments back and forth, analyzing each other’s writing until one of the sides is defeated. I don’t know if I would like that very much, but I know that some people would really enjoy it.

I think part of the reason that I wouldn’t be good at something like a rhetorical analysis is that I am not very good at coming up with my own arguments. I think part of the reason for this is that I was forced to come up with arguments about things that I didn’t really care anything about in high school, like whether the drinking age should be lower than what it is now or not. I don’t really plan on drinking a whole ton of alcohol, even after I turn 21, so interest on this topic was very low for me, and I didn’t have a lot of fun. However, if we were arguing over something like the impact of violence in video games, I would be a little bit more help. I have played several video games, and a few of them were pretty violent, like Star Wars: Battlefront, or Call of Duty. Even though most of the games that I play aren’t really violent, I would still have more to do with that argument than I would with the drinking age. I guess what I am trying to say is that perspective matters. If you don’t care about something you are arguing for, your arguments will seem weaker automatically.

Anyway, on the topic of the rhetorical analysis itself, I don’t really see the point. I was told in my programming class that things go a lot smoother if you don’t try to figure out why everything works, as long as they do. That completely makes sense to me. If you tried to do a rhetorical analysis on every newspaper article you saw, you would go absolutely insane. We all know that advertisements usually try to get us to buy something, newspaper articles try to inform us, etc. As a computer programmer, I won’t really need to know why advertisements work unless I am designing them myself. I will have to write documentation on any program that I write, but I probably won’t ever have to analyze other people’s writing to see what exactly they are trying to do.

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.