Advice to future students from current students

May 6, 2010

It’s the end of the Fall semester, and I am a little bummed. More on that later. For now, I will amuse myself by sharing with you, dear reader, the advice that my students are leaving to future students. Specifically, this came from an anonymous survey in my HCI class. The class was project oriented, 15 weeks on a mobile phone application. In the survey, I asked for “Advice to Future Students,” and the students were told that any responses would be shared.

I will be linking my 315 and 222 students here in the Fall.

The only advice that I can give. Any course taken by Dr Gestwicki is very immersive and practical. If you want to fully utilize his course, dont take any other course or atleast dont burden yourself with too many courses other than the required minimum. I personally felt that I had only used 10% of him this semester and still I found it very enjoyable and wonderful. So imagine how I would feel, if I had utilized him to the full. You can make a living out of any of his courses. Attend all of is meeting( I wouldnt say that as classes) and always dont hesitate to ask him any doubts, even if they are silly. Go and knock his office doors often :)

Tackle the bigger problems first, making about pages, and splash screens is trivial compared to the main functionality of your program.

Consider your scope very very carefully. Consider how you are going to meet that scope. Consider what you want to do and make sure you refine that as much as possible. If you have someone that’s taken software engineering before have them help you figure out a development process that will work for your team. Try and do everything you can to involve all the team members.

start your project eariler,
go to developer guide, if you have some problems with andorid coding
communicate your team more than once per week

My advice would be to always get your work done in a timely manner. This, of course, does not pertain to the specific class alone. Nobody likes the person that never does their work. Don’t be that person, is my advice.

Read your documents and any extra material that you think you may need or even peaks your interest. In this field its always good to stay up to date on the latest information as well as branching out and learning new languages, ideas, and methods for accomplishing a goal.

Also, get to know people a bit before you decide to work with them. Just because you are friends with someone doesn’t mean you know their work ethic or their abilities.

Read before start

A good group makes all the difference, and bigger isn’t always better. Having a good tight group of 4 or so people will keep you organized and agile.

Let me begin with an overarching caveat: when you take a class like this, the majority of your work – perhaps 90% or more – will be dealing with other people. You will pick your project, the difficulty level, and almost every aspect of how it should get done. Furthermore, everyone in a 300/500 level CS course should be able to write code and solve problems. Skill is not the problem. Getting people to do the work is.

Take the hiring phase of this course seriously, even though you may have little time/resources to do so. Once you’ve formed a team, get to know the PEOPLE on your team ASAP, not just WHAT they can supposedly do. Find out if they have a lot of other courses this semester. Find out if their other courses are difficult or easy. Find out whether they will consider this a blow-off class or not. If you find yourself among a team of slackers, leave the team or fire those people immediately. Otherwise, you will probably ruin what could have been a fantastic learning experience in this class.

Additionally, find out how your teammates think. This is especially important (in my experience) if your team includes students from other parts of the globe; not everyone thinks like you. The words ‘testing,’ ‘development,’ ‘design,’ etc. can mean slightly/very different things depending on your background. In fact, even if your team consists of just one nationality, your teammates’ past project experiences may foster inconsistent team-wide expectations. Create a terms list for your team ASAP defining project-related terminology. Make sure everyone is on the same page.

Lastly, make sure you adhere to the following three rules when it comes to working as part of a team:
1. Communicate early.
2. Communicate often.
3. See rules 1, 2, and 3.

The internet will lie to you, only incorporate those ideas and algorithms into your project that you understand.
It is best to address the problem of an unproductive team member early rather than late and to do this in as creative and friendly of a way as possible.
Satisfactory results are not always correct results. Test at the margins; the beginning and end of files, the extremes of input – large and small, and test your project with both an expert and a novice.

Reflections on Situated Learning

April 23, 2010

I just finished reading Situated Learning: Legitimate Peripheral Participation by Lave and Wenger. It’s a fascinating piece of scholarship published in 1991 that approaches learning from a situated, social perspective. An overview of Legitimate Peripheral Participation (LPP) can be found on Wikipedia. Many ideas came to mind as I read this book, but before I go any further, I should mention that this is still relatively far afield from my usual research areas, so I welcome correction if I am missing the nuances or even just plain wrong on my interpretations.

Communities of Practice

The authors describe learning as happening in a community of practice. To establish this point, they leverage a variety of examples of apprenticeship. One of the core contradictions the authors use is that of community regeneration, that newcomers become old-timers. Tying this into higher education, it makes me concerned that much of higher education is designed to propogate professorship. This is almost too easy an explanation for why motivation to study is generally low among college students: the intention of the teacher and the perspective of the student (assuming the student is not intending on an career in academia) are completely different.

Masters such as these

A quotation from p85, in the context of discussing how learning occurs in communities of practice despite the absence of didactics:

If masters don’t teach, they embody practice at its fullest in the community of practice. Becoming a “master such as these” is an embodied telos too complex to be discussed in the narrower and simpler language of goals, tasks, and knowledge acquisition.

This captures some of my frustration in teaching. I reference my working with two students on Confluence as one of my most positive learning experiences, and I feel strongly that we all learned substantially from this experience. Borrowing from Lave and Wenger, my students were legitimate peripheral participants, and I was the master—not the “teacher”. This is in stark contrast to my experience with 345/545 this semester. With 33 students spread across seven teams, I am left barely involved in their processes. I am a master in abstentia, but I can see no other way to organize so many people with one course load.

The other course I have this semester is on history education game design, and I am team-teaching it with my esteemed colleague Ronald Morris. We have eleven students who are working on the design for a game that will teach fourth-graders about Indiana’s Civil War history. While the class has some forward momentum now, there have been several points where I have felt that the students were either not putting in the right amount of effort, or that they were not putting effort in the right direction. I have tried to guide this as a mentor, but looking at it from the LPP perspective, not as a master. I cannot help but wonder what would have been different if I had been the game designer, and the students had legitimate peripheral roles: would that have been a better learning experience for them, with less of the frustration that comes from masterless apprenticeship? I am going to need more time to think about this, but I offer it here for consideration and commentary. (EDIT: I should add that I don’t actually consider myself a master game designer, but rather someone who is learning along with the students. However, my “mentoring” actually separates me from being a legitimate peripheral participant. Weird.)

Lave and Wenger do not explore the structural changes that would be necessary in formal education in order to leverage LPP, but I do not blame them for avoiding that minefield in this work.

Teaching a craft

One of the more interesting case studies referenced in the book is that of the apprenticeship of tailors. An apprentice starts by learning to finish a garment: sewing buttons, hems, etc. The apprentice then learns the production process backward, so the last thing the apprentice learns is how to cut the material. This way, while working peripherally yet legitimately in the community of practice, the apprentice is learning not just the feel of the material, the repeating patterns of tailoring, but also the social interaction and the personal identity of tailorship. The authors claim that this outside-in pattern of learning a craft is common across times and cultures.

I agree with Alistair Cockburn that software development is largely a craft. Are we guilty of teaching students inside-out, from cutting to polishing? Given that students rarely ever truly ship anything, I would answer affirmatively. Understanding this model of learning a craft, and the theory of LPP, has given me a new perspective on an old frustration, but again, I’m going to need more time to digest it.

Team focus vs. product focus

April 22, 2010

On Tuesday, we had a guest presentation in 345/545 by Jim Solenberg, Chief Architect at LaViaz Mobile. He gave a very nice presentation on UI design and development, pulling from significant experience in both the technical and the human factors of application development. He based much of his presentation on the Apple iPhone Human Interface Guidelines (HIG), which are worth an exploration.

Solenberg argued strongly for having a product definition statement that a team could return to for justifying all significant decisions about an application. This is a good idea and, as I understand it, a best practice in application development. However, from what I have seen, the Apple HIG does not address the nature of the team, only the nature of the product. In 345/545, we have been following a loose interpretation of Microsoft Solutions Framework (MSF) Team Model, specifically the Risk Management Discipline. This approach was recommended from Hal Abelson for mobile application development within a classroom environment, based on his pioneering courses on mobile application development at MIT. MSF is product-agnostic, but it heavily relies on collaboration by peers: all members on a team are peers, and open communication is necessary.

Inspired by MSF’s Team Model, I had my students include a team mission statement during team formation. The intention was that this would capture the ethos of the team and give them a stable point, even if they changed projects. That is, even if the team unwittingly undertook a project that was beyond their capacity to complete, they could be agile enough to change projects as long as it was consistent with their team mission statement. This is reminiscent of the Resources-Values-Processes business analysis model from Clayton Christensen, where the mission statement represents the Values of the organization.

Students were asked to give a 2-minute project pitch the same day as they announced their team formation. My intention was that this pitch would contain the “elevator talk” version of the project, the product definition statement of the Apple HIG.

From my observations, I suspect that none of the teams have referenced either their mission statement or their 2-minute pitch since the beginning of the semester. One of these is focused on the team, and the other on the project, but they serve a similar purpose: to steer a team towards success. I am left wondering whether more rigorous enforcement of either would have helped the teams through some rough patches. However, because neither the team-centric mission statement nor the product-centric elevator pitch seemed to have much effect, I am left wondering what elements of this approach should be reused. It may be worth noting that none of the teams have shifted projects since their initial pitch in the first week of class, although all have revised their designs through a few iterations.

Emerging Media Initiative Faculty Symposium Interviews

April 21, 2010

A few weeks ago, we had an Emerging Media Initiative Faculty Symposium at Ball State. A few of the participants were invited for interviews to discuss the impact of the Symposium on the University community. They’re kind of fun to watch.

Here’s Mahesh Senagala, one of my favorite people on campus. I am always impressed by the lucidity of his extemporaneous commentary. Then again, maybe he cheated and actually prepared…&l=1

Here are Petra Zimmerman and I. At this point in the day, I had a ripping headache and had lots of coffee to try to counteract it. (Didn’t help.) However, watching this again, I don’t make as little sense as I feared I would. Clearly, I expected them to cut out some of my hemming, hawing, and wristwatch commentary, and right at the end I get cut off just as I am asking them to do some editing to make me make sense. Oh well, at least my tirade against the plans for the commercialization initiative were not caught on camera. I do not know Petra very well, but she’s quite friendly, from Geographical Sciences, and a climatologist (IIRC).,symp_zimmerman&w=800&h=450

For all ten of you who read this blog, my statements about the relative values of ideas and execution were directed against the last session of the symposium, which was a discussion of institutional commercialization plans. In a nutshell, the plan as presented was that a professor takes an idea from scholarly work and hands it off to undergraduate entrepreneurship majors for business development. Undergraduate education needs to be a “safe fail” environment, and if I have potentially commercializable intellectual property, the last thing I’m going to do is hand it over to a group of 20-year-old non-experts. That’s the sideways point I was trying to make during this interview: that if you have an idea and you want to commercialize it, the right thing to do is hire the best people you can afford to make it happen, not to give it to students for a learning experience. I don’t know if that changes your interpretation of the interview, but that’s a little backstory on my mental state at the time.

Yes, and it is kind of fun to have been mentioned in all three, but fame is a carrot, and I’m busy defibrillating my intrinsic motivation.

A student levels up

April 20, 2010

The following quotation comes from the end of one of my student’s recent reflections. This was private correspondence, but the student gave me permission to quote it here.

On an unrelated note, working on the exercises you’ve given us has presented me a sort of humbling fact: I have no idea how ANY of the stuff I’ve actually put together works. I mean, it certainly works, but if I were asked on the spot how certain practices directly impact the design of my program, I’d be more or less speechless. Obviously, I’m learning these things now, but I wonder how much of the design process would have been more smooth had I actually followed these best practices on the spot. I’ve basically been applying the practices as seen from certain examples I’ve pulled inspiration from, but it dawns on me that I didn’t actually realize they were there. I’ve read a bunch of the materials you gave us access to, but it really didn’t hit me as to how effective the practices can be in your program.

This is one of the most honest and inspiring expressions I’ve read in any of the reflections. It is a heartfelt admission of vulnerability. This is humility. This is gazing up at the night sky and realizing how much there is out there. This is demolition of the ego. This is victory over second-order ignorance. This student is ready to learn.

Colossally Bad

April 19, 2010

I was at the last meeting of one of my committees this morning, when someone from the Humanities mentioned that traditional higher education has worked pretty well for the last hundred years or so.

I replied that we are colossally bad at higher education.

The rest of the committee was a little taken aback by my comment, so I briefly tried to justify it, though I admit I did not do a good job. I still believe that, for the most part, students learn despite higher education and not because of it. We know that humans have a limit to their attention and capacity to learn, and yet we insist on putting students through an industrial education model. We are glad that our students get jobs and make money, but we talk very little about quality of life and preparation for lifetime learning. This is knowledge work, not factory work.

Given the amazing and accelerating interconnected complexity of the world’s problems (many “wicked problems”), I am more and more convinced that teaching students a smidgen of any one topic is really not worth the effort — whether that’s literature, computing, architecture, etc. If students cannot grok the interconnectedness of problems, they will continue to be tools of those who do.

From personal interaction to online reputation

April 18, 2010

Yesterday morning, I decided to roll out a new version of Connect the Dots in hopes that it would fix a bug due to Motorola’s Droid OTA update. In case you haven’t followed the story, Motorola released an update about two weeks ago that made my game nigh unplayable. This only affected Droid, and I don’t have a Droid, and so that made it very tricky to debug. I tried recruiting help from a Droid-owning cousin and even some of the kind people who emailed me bug reports, but the truth is, most folks only know how to install apps from the Market. It’s not intrinsically hard to install from an APK that someone emails you, but the Android team didn’t go out of their way to make it easy either. Must not be a key scenario.

I pushed out version 0.2.2, took a shower, and then downloaded the app to my Nexus One to make sure it was still happy. Running the app, I realized that I inadvertently left some experimental code in one of the classes, and suffice it to say that it led to suboptimal user experience. By this point, it was around 8:30am, and I need to be on campus for a prospective student fair by 9:15. I booted my development machine into Linux — my preferred development OS — only to find my screen would not go to a resolution above 640×480. I have no idea why, but Win 7 did this to me the previous day too, and I did not have any interest in figuring it out then. Reboot into Win 7, where I realize I did not have the ADT plugin installed for Eclipse. I run the installation, and suddenly I can no longer browse my svn repository. No repository, no code. I come very close to throwing anything I can find, then rush off to campus, hoping that I have everything I need on my office workstation.

(Also, it’s my sixth wedding anniversary, I haven’t even said “Happy Anniversary” to my wife, and I’m heading into a day at work, plus my bike is in the shop. Let’s say I was not in a good mood.)

Fortunately, my office workstation is all set up, so I update my working copy of Connect the Dots and start investigating. Sure enough, I had made a mistake when pulling from an old tag into the trunk, and some of the experimental junk code in the trunk had not been overwritten. Fortunately, all I had to do was copy all the changes from tag 0.2.1 into the copy in the trunk — version control FTW. I go to check to make sure this version is working correctly, only to find that I don’t have a micro-USB in my office so I cannot hardware test 0.2.3. Par for the course. It can’t be worse, and the emulator shows that at least the experimental code is gone, so 0.2.3 gets published.

That’s all the backstory. I show up at Cardinal Preview Day along with Josh, an amicable undergraduate who agreed to help me talk about the department. He’s kind enough to listen to my story while we get our complimentary coffee. We stand by the Computer Science table as prospective Ball State students meander around, learning about different departments.

The second group to stop by consisted of a young man and who I assume to be his parents. He had just been to Purdue to talk to their CS department, and so he and his parents had some very pertinent questions. I have fielded these questions before, so I was ready to discuss some of the qualitative differences between BSU CS and Purdue CS. This group stayed to talk for a while, and I think I counted three other family groups that joined the periphery of the discussion. I tried to address the first student’s questions while sharing other information over his shoulder to these other prospective students.

He asked about some of the work that was shown on the display behind me, so I went through a litany of some of the interesting student projects we have going on.When I mentioned that I am teaching HCI through Android application development, he stopped and asked if we had anything on the market. He reaches into his pocket and pulls out … you guessed it … a Motorola Droid.


Actually, that’s what my brain said, but my mouth knew better. I explained that I had just uploaded an untested update that I had no idea whether it would fix a Droid-specific bug or not, and he was kind enough to oblige. I actually brushed off a real question or two while he went to download it. This was important. He opened the Market, did a search, downloaded the app, and presto! It’s working perfectly! Que alegria!

The rest of the day went on as expected, and mid-afternoon, I took a moment to check out the reviews on Connect the Dots to see if people had gotten the update. Recently, there had been a lot of comments on how it was broken on Droid. There were already four positive reviews thanking me for fixing the Droid bug, including this five-star review from “Eric”:

Met the developer at ball state, he’s a cs prof. This game is great!

Thanks, Eric, for brightening the day of a frustrated developer.

Postscript: Motorola’s update botched their handling of points as size specification. Points are defined as 1/72-inch, which is resolution-independent. It seems that after the update, my specification of the dots as 12pt radius was misinterpreted as 12-pixel (12px) radius. I changed the dimension specification to 24dp, where “dp” is “density-independent pixels”, which are pixels as if you are running at 160dpi. Note that both pt and dp are resolution and density independent. The change to dp did not change the behavior on my G1 running 1.6 or on my Nexus One running 2.1-update1, but it did fix the bug on Droid. Dear Motorola: it’s hard enough to support the variety of Android devices without your breaking spec.

Glad not to be needed

April 8, 2010

This morning was the Emerging Media Initiative Faculty Symposium at Ball State. I gave a very brief talk in the “research/education-related projects” session about my experiences teaching Android application development first with non-majors using App Inventor for Android and now with majors using the Android SDK. I think the talk went well, and I’ve received some nice feedback. It may be visible online, but it’s not working for me at the time of this writing.

The event was scheduled to go until 12:30, which is when my class starts. I agreed to be interviewed about the role of emerging media and the symposium, and so I knew I was going to be late to class. I notified my students, asking them to use it as “consulting time”: to work on their projects in teams, help other teams, and generally be productive.

The event and interview went longer than planned, and so I didn’t get to my class until 70-minutes into it, and it’s a 75-minute class. How wonderful to walk into the room and see all my teams sitting in groups getting work done! Thanks to these students for inspiring me with your diligence and dedication to your learning. It’s a great feeling to know that I have done my job: setting you up so that you can get it all done without me.

Higher education desideratum: intentional completion

April 3, 2010

Desired: a learning environment in which participants engage in intentional completion. That is, they “ship” their work when they decide it is time: not when the semester ends, not when a deadline looms, not when they want to give up.

One of the main reasons we don’t have this is the conventional grading system. What is needed is continuous formative evaluation. What we provide are punctuated summative evaluations: grades during the time-boxed learning experience directly impact a final assessment. This does not provide a “safe fail” environment necessary for real learning. Real learning happens when contradictions within the mind are discovered, and that essentially requires failure. I contend that building an environment to support intentional completion requires embrace of failure and therefore the abandonment of conventional grading.

Ontological argument for the existence of software

April 3, 2010

I gave a talk two weeks ago in a seminar on design thinking and innovation. As I was preparing for the talk—not knowing exactly what to talk about, but knowing that it should relate design thinking and software—I got to thinking about what software is. It is intangible but has behavior. It must exist, then, but it cannot be sensed. We can interact with bits and pieces of representations of it, but I contend that none of these are the software, not in toto.

This led to me to define the ontological argument for the existence of software, with apologies to Anselm of Canterbury:

Software designed is software created.

Put another way, software that has been designed with sufficient specificity so as to be implemented has already been implemented, modulo syntactic transformation. This is intentionally stated as a material conditional, implying that software can exist which has not been designed, but software designed cannot non-exist.

For example, consider the design of a software system. If this design cannot be implemented, then there is an omission, and therefore there exists a design which is more rigorously specified. For any hypothetical software system, then, there exists “a design than which a greater cannot be designed.” In creating the design, one has created the software: the executable model, the mathematics over time.

(What about the defects, you ask? They are baked right in. I never said that we are good at design!)

One of the seminar participants suggested that this makes software similar to an argument, which exists in the mind and can be represented on paper, but the representation is not the argument. This is a keen insight on the nature of intangibles, but it misses the point that software is an executable model. I was presenting primarily to young architects who are comfortable with static models, which clearly exist, even if one argues that the idea of the model is distinct from the physical manifestation of it. I understand that there is a shift in architects towards parametric models, and the relationship of these creations to the software development process is one that merits investigation.