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.
No comments:
Post a Comment