Robert Young
English 250
Section PN
3/12/2014
Software Engineer
Communication
My paper will be
about the methods that are used to communicate ideas between Software
Developers in a small group setting as well as analyze the ways in which
Software Engineers coordinate their work, so that no job is left behind or done
twice. I already know most of the media by which Software Engineers
communicate: Face-to-face, code, email, etc. I would like to learn what kinds
of things they put in emails, whether the face-to-face meetings are more formal
or informal, etc. It would be also interesting to learn where this communication
can fail, and what can be done to prevent failures from happening any further
down the road.
In my paper, I
plan to cite several articles from peer-reviewed journals that cover the types
of communication that are used in Software engineering as well as why they are
used, and how. I will also use a couple of visuals to emphasize how well
certain types of communication work better than others for certain tasks, and
which type of communication is better overall.
In the first frame, the
cat is kind of just a sketch, just like when a Software Engineer has the very
first idea for his program. You have a basic idea of what it looks like, but
not necessarily exactly what it will look like or what it does. It hasn’t
actually been started yet, and there will be a lot of work to do, just like a
program needs to be developed before it can actually become what it was
intended to be. When I went back to look at this later, I noticed that some
parts of this first frame are done in great detail, like the head, while others
are just barely started, like the legs. This may be because some parts of a
program have to be explained a lot for it to make sense, while other parts make
sense intuitively.
The second frame is a
representation of how much time has been spent on each part of the program.
Notice that the larger percentages of time are spent on things that are just
kind of off to the side, like the tail and legs instead of the torso, or head,
which is kind of like more time was spent on bonus features instead of the main
program. This isn’t always a bad thing. Sometimes you get done with the main
part of the program, and would like to add some features, but the features are
actually more complicated than the main part of the program. Usually
programmers use things called functions, and these functions help out the main
part of the program. On a cat, the legs help the cat move around. One of the
more complicated parts of the cat, the tail, helps keep its balance, which is
extremely difficult to simulate, and may take more time to perfect than the
rest of the cat. It is things like that you have to take into consideration.
The next two frames go
together. One is labeled “How the Software looks before the beta test,” and
depicts the cat with its hind legs missing. In the analogy to a computer
program, this would mean that some features are missing, but most of the main
functionality is there. After the beta test, in the second of these two frames,
the missing functions are there again, but now different features are missing. This
kind of helps explain that no program is ever complete. Every time you change
something, it seems like it caused something else to be broken. In this case,
adding the hind legs accidentally removed the front legs. 
The first frame in
the second row is labeled “How the software is advertised.” It displays a
ferocious-looking tiger. This cat does look a lot better than the other cats on
the page. It is depicted as a tiger that could supposedly run at up to sixty
miles an hour and swallow a small child whole, even though the cat that is
illustrated in the rest of the image probably wouldn’t be able to do that. This
relates to Software Engineering because software often claims to do things that
it actually doesn’t do very well, if at all. From personal experience, some
applications on the Windows Store claim to do things that they don’t actually
do. I won’t list specific examples because most of those have been fixed now. 
the cat-program even
if they wanted a dog-program or even something completely unrelated, such as a
flower-program. This is something that I myself do not necessarily agree with.
If Software Engineers are unable to produce exactly what customers want, then
why have them? The software engineers have to have something to work towards,
even if not everything is explicitly stated for them. What the customers want
is known to the Software Engineers, they just might think of a different way to
do it than the customer wanted.
The second-to-last
frame, the cat with the arm sticking out of its back and the elephant trunk
growing out of its nose seems a little out-of-place. To me it looks like
features were added that weren’t really wanted (or intended). It is kind of symbolizing
a computer bug. It is a side effect that wasn’t expected or intended, but is part
of the program anyway. In software engineering, bugs can sometimes be hard to
get rid of, and getting rid of them can sometimes lead to more problems. To
relate this to the picture, I don’t think this cat would appreciate us chopping
off the arm on its back, and it could create a very large mess that would be a
pain to get rid of.
