Reflection #5

Aural Aura Status: NO GO
Perhaps my standards are different than others, but from my vantage point, it seems several of my teammates have been dragging their feet all semester. There was a little anxiety and scrambling at the end, as is natural with most procrastination, but the tiny bit of energy and motivation derived therefrom is for naught. There were so many team/individual issues (poor attendance, poor communication, results not submitted on time, etc.) that hindered our progress earlier in the semester that producing a solid release candidate by Thursday is now not possible.


Why did some Drag their feet?
A good question. A small part of the answer might stem from the hybridization of classroom space and industrial space. That is, if we were purely in an industrial space, personnel might be fired, voluntarily jump ship, be bumped down in rank, made to do mediocre work for a period of time, etc. Threats of unemployment and the like might have imposed a sense of fear which in turn may have spurred teammates to continue working. However, because the team experience is a big part of the learning process in this class, some industrial space practices conflict with classroom space, (e.g. no team in the class would want to hire a just-fired person, and thus should someone find himself fired, he would miss out on a valuable team learning experience). Marginalizing team members to do mediocre work may afford them low or no educational return. If someone were to voluntarily leave a team and not be assimilated by some other team, he would obviously and likewise miss out on team-based learning.


Another part (and the largest part, in my opinion) of that answer has to do with pure human nature 101. Who likes working hard? Why work hard when we can take it easy? Who likes rushing to get stuff done on time? Who likes having to rack his brain? Who likes having to dig for information? I think in the purest sense of these questions, the answer is either no one or few. I believe there is a certain nature within all of us that expects perfection and easiness about everything we do. Overriding the discomfort of putting forth hard effort is therefore alien, undesirable, and an acquired skill in and of itself. I think most of us have our own extrinsic motivations for working hard, getting stuff done on time, digging for information, and racking our brains. When those do not outweigh the counter-motivations implicit in the questions above, we stall, avoid, and give up.


Some Hard Facts
Little testing of code has occurred this semester, which is partly due to developers not having written much code prior. Also, the fine line between the meaning of "testing" and the meaning of "development" has just recently become apparent. Why? I think the clear distinction between the two has been obscured by laziness or perhaps second-order ignorance... or perhaps both? The why's behind the other facts are answered below in What have I Learned this Semester?


What have I Learned this Semester?
To answer this question, I think listing most of what I've done is probably a good place to start:

• Generated documentation
• TODO list
• Milestones list
• Roles & Contact info list
• Meetings log (outside of class)
• Meetings log (class)
• Meetings schedule
• Algorithms
• Devised and implemented processImage(Bitmap bmp)
• Co-devised processImageMetadata(ImageMetadata md)
• Posters
• Designed layout (both times)
• Acquired graphics (both times)
• Wrote all text (both times)
• Physically went to print out the first poster (okay, a small achievement, but I'm still counting it!)
• Paid most of the cost of the first poster (second poster was electronic)
• Outside partner
• Scheduled and led first outside partner meeting
• Sketches
• Flowchart for how the app will work
• Mock-ups for the various screen GUIs
• Code
• Software architecture
• Designed
• Implemented skeletal versions of classes for all but a couple
• Pair-programmed for some classes, fully wrote other classes
• Fully wrote:
• ImageProcessor.java
• ImageMetadata.java
• RadialInterval.java
• Quadrant.java
• Pair-programmed all else
• Wrote Javadoc comments for most classes...
• ImageProcessor.java
• DataCenter.java
• KeyboardScreen.java
• PainoKey.java
• RadialInterval.java
• ImageMetadata.java
• Quadrant.java
• AuralAura.java (deprecated)
• Graphics
• Designed and provided the MainScreen.java background
• Designed and provided MainScreen.java interface custom buttons
• Designed and provided the HearImageScreen.java interface background
• Designed the HearImageScreen.java interface custom buttons
• Presentations
• Primary presenter for the vast majority of class presentations
• Meetings
• Scheduled meeting times and places for about 2/3 semester
• Led meetings outside of class

I've learned that Android programming isn't all that difficult. The SDK is very easy to understand, mainly because things are done in Java. I've learned that in team management if one doesn't hire properly, his job can be a nightmare. If I were to repeat this course, I would certainly have taken the hiring phase a lot more seriously.

I learned that I could have done even more than what I listed above... perhaps even completed the project alone well before the end of the semester. However, when some are asked to do work, I don't expect that others should have to work redundantly on the same thing. Redundancy is good sometimes, but too much can be problematic (i.e. resources are overtaxed). Also, in terms of fairness, if one person did all of the work for five people, there would obviously a problem with classroom space (e.g. some would basically learn nothing).

I am encouraged by the amount and type of work I've done this semester. It further reinforced my confidence and motivation to become a decent hybrid professional, capable of both design and development.

Considering all that I've learned this semester, I would say that though we failed in industrial space, I succeeded in classroom space.

Individual vs. Collective | Reflection #4

Asking for Help & Pair-Programming

Consider the following quote: "programmers... a notoriously independent-minded category" (Fogel, 11). I would argue that one could extend this quote to include developers and perhaps computer scientists in general. Regardless, I think this quote may be of some help in isolating a possible explanation for the lack of peer Q&A among AEIOU team members. That is, I think there may be some cultural expectation of individual excellence within out team. I, personally, think this is a double-edged sword. On the one side, this aura, if you will (no pun intended), may motivate team members to learn/do more. On the other side, it may act as a source of fear and paralyze forward movement.

When should we ask for help? When is it okay to be wrong? When is it acceptable to show weakness? What about the following: Never asking for help. Never being wrong. Never showing weakness. The second of these is humanly impossible; so, let's throw that out. The first impairs growth, and the third implies a false posture at least some of the time. When considering self-improvement, how do either of these help? Not asking for help and barring growth implies a fairly obvious answer: it doesn't help! And, never showing weakness (in this context) is (in my humble estimation) a closed door to possibilities for improvement. Notice that I've not yet answered my original questions. When should we ask for help? I think: as soon as possible. When is it okay to be wrong? I'm not sure I could answer this fully, but in a learning environment, being wrong is a common part of the experience, especially at the beginning of any new endeavor. When is it acceptable to show weakness? This may be a little tricky to answer, but never showing weakness may lead others to think one "has it all together" when the reality is the contrary.

I remember at the beginning of this semester, I would tell my teammates to "ask any question, even if it seems simple or silly." I am only now, in the latter part of the semester, receiving questions about fundamental issues regarding programming for Android and programming in general. I don't know if the aforementioned cultural taboo is to blame. I think many factors were at work in silencing potential discourse.

All this to say, pair-programming is awesome (as long as everyone shows up). However, individuals with more experience need to cut out their pride and truly ask for input from others; the sessions go much more smoothly this way. The tricky part for the seasoned programmer, in my experience, is knowing when to ask and what to ask of the other not-quite-so-seasoned programmers. This approach helps prevent an inauthentic atmosphere and the appearance of hand-holding, and in my experience, it also leads to more outside-of-the-box answers.

Well, that is all I have for now.

Cited Sources:

Karl Fogel. Producing Open Source Software: How to Run a Successful Free Software Project. (2005-2009).

Individual vs. Collective | Reflection #3

Team = Collection of Individuals

Individuals are still individuals, even if those individuals comprise a team. I find the notion of succeeding or failing as a team to be rather intense. Although implications aren't explicit, it would appear that team successes and failures occur w.r.t. the entire team's involvement. Rarely has this been the case in my experience.  Usually, there are a couple of champions in what I like to call the champion led model (CLM). That is, if a team can be classified as a CLM, there will be relatively few persons on said team who are both competent and motivated to the success of the team's goal(s). These champions usually do the majority of the work while others drift along contributing moderately or even marginally.

Of course, champion is a relative descriptor; if everyone contributed at the same level (or even at approximately the same level), there might be a better sense of contribution equity? Might then the team better reflect that which it claims to be: a team? Then again, a team is more than just a group of individuals giving it their best at their individual tasks. These individuals need to communicate with one another to avoid, among other things, duplicating work. For simplicity's sake, let's just consider individual communications with the team a subset of individual contributions to the team.

I mentioned that succeeding or failing as a team seems a fairly intense notion. The intensity to which I am referring appears to be founded on a relationship between individual goals and team goals. Based on the team goal, one person may be highly motivated to contribute to the team... and another, not so much.

A simple military example might look like a squad of soldiers sneaking quietly through jungle terrain in an effort to get out of a hot zone. Each soldier is highly motivated to contribute to the success of the team's end-goal: stay alive. That's because the team's end-goal is also each individual's end-goal! So, it would seem (naively) that if E is an equals relationship, E(individual goal, team goal) may give us some insight as to the motivation and thus contribution levels of a given team member.

We might also have said that the individual goal was to stay alive and that the team goal was to get out of the hot zone. The relationship would then be defined a little differently. Here's an example illustrating this relationship. I mentioned in a previous post that I was part of a mobile development team where each individual was highly motivated to succeed. I am almost certain that the following goal was owned by each member: put something cool on my résumé. The team's collective goal was of course to make something cool. The team's goal here was a means to an end for the individual goal. We might call this a dependent relationship between goals, or D. Although E is a fairly interesting relationship when considering goals, so is D. I am not sure which one is more powerful/useful.

...actually, upon further thinking, I am not sure that the Internet itself could hold all that might be said here! I suppose then that my reflections in this post aren't quite that robust. Nevertheless, I still believe this stuff is important, and I am prepared to reap what criticism may come my way. Besides, the idea of never going out on a limb kind of bothers me... and leads to life in a very small box.

Moving Along | Reflection #2

Considering Context | Overly concerned?
I have no doubt that team AEIOU could whip up an Android application in one week if we all sat down together for 20 to 40 hours and just coded away. However, the end result might not be user friendly. Usability is critical, but just how much should we be worrying about that right now? We have already, in my opinion, inordinately thrashed a super simple app. When it comes down to it, disputes concerning "what the user would like" are the main sources of lag for pushing out our first alpha. Said disputes tend to be about trivial and/or technical things:

1. Since the alpha will only implement one source for images, should it be the camera, gallery, or Web?
2. Should we go straight to the camera, keyboard, or main menu when the app starts?
3. etc.

As an aside: I say trivial, but someone else might differ with that.

Right now, we don't have solid user feedback for a running app. Answering "what the user would like" is difficult at this point. So, let's not get tied up in picayune minutia, let's get the alpha built, and let's put it out there for users so we can get decent feedback! We can always reorder or augment a navigation map later.



Flexibility & Structure | Motivation is fuel for agility?
What motivates each one of us? Why is that the case? Is each motivation exclusive to a context? Can we control our motivations, find new ones, impart them to others, or eliminate them?

I've worked for the Digital Corps for about 3 years. During my employment, I've observed that the most prominent personnel in the Corps are both talented and motivated. I have had the pleasure of working with a highly motivated 4-person team recently whilst working on an app for the iPhone. I would say that the level of agility for that team was extremely high - a 9 out of 10, you might say. I don't think that level of agility would have been achievable if it were not for each individual's motivation to succeed. No one had to be told to do his work. If anything, we were constantly asking one another "what do you need from me right now?" I recall several times asking for a single graphic and getting 3 variations in return. We were not just motivated to get this app done... we were motivated to be the best at whatever it was we were doing. We saw the task of completing this app as not just something we "did for work," but as a testament to our abilities. I think each of us knew this about each other, and we chose to capitalize on the potential synergy.

I think everyone on team AEIOU is fairly comfortable in his respective role, but something still seems amiss. I can't quite put my finger on it. Perhaps the newness of this experience for some is keeping them at a fork in the road when it comes to what exactly should I do next? That was natural for me, too, at first. Well, our team is employing a few new structural tools. Until our new tree grows a bit more, we will keep the stakes close by. Given a little more time, we'll grow into a mighty oak!

Team Dynamic | Reflection #1

The first thing I would like to reflect upon is an initial response to our team and its progress. Simply put, I do not sense that our team has found the cohesion is needs to make progress as rapidly and effectively as it should. I start on this negative note because it is the one that stands out most to me. I might have started with a positive note, and there are several, such as the interesting discussions about sound, synthesis, color, perception, usability, and the like. However, those positives seem to be free-floating and not recorded concretely or part of a detectable overall process or plan. Also, I am unsure as to whether all of the discussions that took place were necessary given the immediate goals, the amount of time we had, and the level of foreknowledge for a given discussion.

It appears that little time is devoted to our immediate goals while much is devoted to goals far out in the future ...or perhaps infeasible.

I think part of the problem (for my part, at least) is that the MSF Team Model has not been clearly cemented in my mind until, I think, today when I reread it. Much to my surprise, several of our team members exhibit motivations to address several "Functional Areas" - the sub-roles or sub-goals of any given role in the MSF Team Model; however, these motivations seem to be for Functional Areas in roles other than the ones assigned!

I really believe that our team has a solid application it can deliver. The application (Aural Aura) is most certainly designed for mobile use: it's functionality is simple, quick, to the point, and understandable; not to mention it makes use of technologies usually found in mobile phones (a camera and sound playback). However, I think our team is perhaps like a kid's bike assembled by a proud dad who refuses to read the assembly instructions... not a good outcome. That is, I think we have all the talent, knowledge, and skills we need to be successful, but we need to reallocate them.

Thinking upon this line of thinking, I conclude that I am simply a "know-it-all," type-A, control freak who, maybe, just can't stand to be a part of a team structure with the level of flexibility and agility the MSF team structure presents. I am vexed - should I step in and recommend a restructuring of the team? Or, should I just observe the status quo and watch as the current role assignment eventually proves the agility of the MSF Team Model effective?

Hmmm... perhaps the MSF Team Model would prove itself more effective if roles were, indeed, reassigned. I have to believe that roles are assigned to the best person(s) for those roles. The goal of "shipping" - delivering the final product - is a recurring theme throughout the whitepaper. The perception that the team is a single unit without individuals to blame is also reinforced continually. It would make sense that each person on the team takes roles most suitable to him, so as to minimize the social hiccups within the team... so that, indeed, the team is perceived as one unit that operates smoothly.

I was thinking about this line of thinking as well - why should accomplishing the goal of "releasing an app" force teams to attempt the optimal assignment of roles? Now, I don't mean to be rude or disrespectful, nor do I mean to undermine the goals of the course. I just wonder: is it "okay" to flounder in a role not suitable for oneself if it means learning more as a result of the floundering? For this reason, I have remained silent on certain issues, not knowing if my speaking would stem the learning process.

Hmmm... maybe not. After all, the entire team suffers then, doesn't it? If one cog in the machine won't turn, what happens to the rest? Since the MSF Team Model stresses the team rather than the individual, and since the course uses that model, perhaps it is safe to say that the intent for optimal learning in this course corresponds strongly to optimal team role assignment? How can any individual learn if the entire team is in a stalemate?

On one level, I think it selfish to make suggestion upon suggestion and thus appear to be pushing the team around. However, maybe the real selfish thing to do is withhold my suggestions in attempts to avoid negative feedback. If indeed my suggestions would help the team as a unit accomplish its goal, then I should make suggestions regardless of the prospect of retaliation... however minimal or maximal that retaliation might appear.


I suppose I will make my suggestions to the team after all.