Musings about my Profession (and a bit more)

What it means to teach

Eleni Stroulia — Sun, 02 Dec 2012 17:59:58 +0000

We just lost a colleague in my department (http://piotrrudnicki.blogspot.ca/). He fought intensely, but for far too short a time, the disease that, in Greek, we do not name; we just say the “cursed disease” (η επαρατος αθενεια) afraid to invoke its name because just to say the name means to touch the thing…

It was the first such loss that I have witnessed in my immediate professional circle and it has been a shock! We spend so much time at school, we invest so much of ourselves in our school life, that our colleagues are almost family; somehow the word “colleague” does not seem big enough to cover the influence that these people have in our everyday lives. And this is particularly true for Piotr!

Piotr was a particularly compelling personality: intellectually honest, with precise positions on everything he cared to have a position about, with a sharp wit and language, and completely authoritative! He was in fact a bit scary; he always made me feel that I had not thought hard enough about whatever we happened to be talking about, be it programming languages or Greek tragedies.

And this was his “secret sauce” in teaching: to push his students hard, to make them responsible for their learning, to make them put into learning as much effort as they could, and more, before asking (and having) their questions (answered). There are so many stories about how tough he was with students who showed up lazy in his office, how unforgiving he was to those who felt they were “clients”, entitled by their tuition to answers by him, the “provider”. And there are many stories about his patience with students who came to him with “stupid questions”, which they had reached after study… Recognizing that talent is not equally distributed, he did not demand that his students perform well; he *did* however demand that his students put in all their effort and perform to the best of their ability! In addition to his regular teaching, he taught for a long time the team training for the ACM competition, and he also volunteered his Saturday mornings to teach high-school students who were interested in computers. He taught the highly talented, the ones who had chosen (for one reason or another) computing as their profession, and the wannabes. He did not teach just the easy ones who “got it” and were likely to succeed in the end, he taught everyone who cared.

And he always said that “there are two types of students: the self taught and the hopeless; our job is to take the latter and make them into the former”. I am not even sure I completely agree with this statement, but I am impressed by the guts it takes to admit that we are responsible not for teaching our students the subject matter of whatever the course outline proclaims the course to be about, but rather for teaching them to learn. That’s a much taller order than teaching them facts and procedures: if a student cannot learn facts and procedures and fails at the end, it may be because of a variety fo reasons: they came to the course with insufficient background, they are somehow not able to learn this material… But if a student does not learn to learn, if a student does not improve in his/her ability to learn, then the failure (it seems to me) rests much more on the teacher, because, no matter where one stands in the ability totem pole, everyone should be able to learn something and improve a bit.

I am getting ready for two courses next term, and I will try to think about them both a bit differently… I will try to think about them in “the Piotr style”…

Domain-Specific Languages and Web Services

Eleni Stroulia — Mon, 28 Mar 2011 03:05:00 +0000

This past week, in my graduate class we discussed “system integration and agreement at the semantics level”. My class is about “web services”, a subject which I have been covering in a variety of ways in the past two three years.

In one offering, I covered the languages and the technologies in great detail.

In another, I saw the subject very generally (as an integration technology) and I asked the class to develop an integration project; that time, most students decided to use/learn REST APIs and we ended up talking a lot about a variety of web-based user-interaction REST-based tools.

Next, I decided to devote a substantial part of the class to “services science” readings, examining the overlap between web-services technologies and the issues around developing and offering services, based on software.

This year, I started with an introduction to software architecture, then moved through a review of middleware technologies for distributed-software development, then discussed WS* and REST, and reached the point of discussing the semantic-web vision and current state-of-affaires last week.

Among my favorites over the years have been the papers in the 1995 interoperability issue of the ACM surveys, and especially Frank Manola’s paper on “Interoperability Issues in Large-Scale Distributed Object Systems”. The core idea of that really nice short paper was that different types of middleware support different degrees of interoperability and assume different types of agreement between the to-be-integrated software systems.

For example, at the most basic level, a marshalling/umarshalling middleware guarantees the interoperation of two systems at the level of “exchanging values” when the systems in question agree at the level of data representation.
Remote-procedure-call middleware guarantees the interoperation of two systems at the level of “invoking each other’s procedures”; to that end, in addition to be able to exchange values (as operation names and parameters), the to-be-integrated systems must also agree on a (set of) basic message-exchange workflow(s)
And then we have the vision of semantic interoperability, which requires agreement at the level of semantics, so that each object shared by interoperating systems enables semantically consistent inferences by each of these systems.

Reviewing this idea in class, we talked a lot about how semantics might be defined:

in terms of a vocabulary, whether closed or systematically extendible (so that data tuples across systems can be mapped);
in terms of a data model, potentially hierarchically organized in a taxonomy (so that properties of data elements can be transferred across systems based on inferences relying on the data-model relations); or
in terms of a full-fledged ontology, where inferences can be made on the basis of rules defining invariants within and constraints across data elements.

This discussion helped me rethink the methodology behind (a couple of) our recent project(s) where we have been developing (a) a multilayer domain-specific language for characterizing a domain and the various systems in it, (b) a web-service infrastructure for maintaining this model and extending it to cover more systems in the domain by mapping the system-specific domain models to the general language, and (c) web services for querying the data model in a manner that makes the underlying distributed infrastructure transparent to the issuer of the query.

It seems to me that this particular methodology (as exemplified in SociQL, Diego Serrano’s thesis work) represents a sweet spot in the quest for semantic integration, including

the SociQL language at three levels of abstraction
- the basic level of SociQL defines a closed data model (a few terms and relations among them) in terms of which social systems can be understood
- at the next level refinements of the basic data model can be expressed to specify the system-specific data models; these refinements are guided by the semantics of the basic level – in fact, they have to be specializations of this basic model
- at the third level we have the actual data across the various systems
services to populate the third level of SociQL by invoking system-specific data-access procedures, whether they are web-service APIs or SQL queries, and
services to extend the second level of SociQL by defining mappings of data models of new social systems to the basic SociQL level.

In this methodology, the semantics is not explicit (not declared in a formal language); instead it is captured in the web services that map new systems (and their data models) on SociQL. This is both a shortcoming (in principle, explicit semantics make system more explainable and maintainable) and an advantage (since it allows “malleable” software implementations to map systems to the shared SociQL model).

I am not quite happy with the clarity of this document (and I will need to keep working on it on my head) but it just feels like it is maturing and I hope it was not too prematurely born and it does not read terribly mishappen.

The Second Smart-Condo Think Tank!

Eleni Stroulia — Sat, 19 Mar 2011 02:24:11 +0000

Today was (a) the third Day in the Life of the Digital Humanities and (b) the second Smart-Condo Think Tank! So I got to participate to the latter and blog about my participation in the context of the former. I managed only two entries:

I am reproducing both posts here.

The Smart-Condo Think-Tank Day

Having seen many blog posts already, I feel that I am a bit late and more than a bit irrelevant Not only that but I am also too busy talking to type a blog:-)

The Smart-Condo think-tank, the second in what I hope is a series, is going very well. There is interest and commitment from the administration, excitement from the core team, new students joining (and hopefully getting more excited by the minute), and new potential team members.

I am also terribly excited to meet people from architecture psychology and human ecology who are interested in studying and analyzing how people interact and interpret (I particularly like this word in this context) the objects in their environment. These questions are fundamentally humanistic in nature. And it seems to me that there is a fundamental duality around design (of buildings or esthetic artifacts or documents) and perception (by occupants, art lovers and readers) and emotional reaction. And as more an more of our design, construction and perception is mediated by digital media, the subject matter understood to be included under the heading of “Digital Humanities” will expand. And that sounds exciting to me!

DayOfDH almost done

The Smart-Condo Think-Tank has concluded with many good ideas exchanged and lots of plans advanced. It was among the most successful meetings of this type that I have attended; we actually got a lot of things accomplished, including

report on our progress since the last one (more than a year ago), which made us realize that we have done quite a bit of work since then;
outline our plans for the future and identify roles that potential partners can play; several participants seemed to be engaged in the discussion and I am hopeful on the potential extensions of our team; and
listen to our participants’ plans and think about what we could do to align our agenda with theirs.
What was really interesting was our demo of the Smart-Condo platform and functionalities with our Smart-Dollhouse deployment!

We have explained how the Smart Condo works quite clearly.

We have diagrams of the software architectures and process.

We have pictures of the sensors and how they are attached to furniture and appliances.

We have videos and virtual-world simulations.

And yet, when we showed the dollhouse, and let the mom-doll (and it was a mom doll, how could it not be?) cook (by sending hot air through a blow dryer to the sensor attached to the stove), and had the stove light up in the virtual world, and had the virtual-world alarm go off after a minute “warning” about the long-term heat of the stove, and had the light in the dollhouse kitchen switch on automatically to signal an alarm, there seemed to be a “aha” moment in the audience! And that was fun!

So, lesson#1: there is something seriously important going on with simulations and our pedagogy in simulation-based learning is je right thing to do.

And lesson#2: the fidelity of the simulation is important, and finding the right medium can make the difference between working and not-working!

Happy DayOfDH!

My day was interesting and intellectually engaging and productive, all in all a lovely day, under a bright Alberta sun (we were allowed breaks out of the rather grim classroom where the meeting was held) and blue sky!

And then I went back to my office (and I got surprised at my two windows, they seem new and lovely every so often) and had a great chat with my students and a long laugh at some apparently half-baked University initiative.

Life is good!

Maria Klawe on “Teaching Trials and Triumphs”

Eleni Stroulia — Tue, 08 Mar 2011 06:59:31 +0000

This afternoon I attended Maria Klawe’s keynote for the UoA’s Festival of Teaching 2011 (https://provost.sitecore.ualberta.ca/en/FestivalofTeaching2011.aspx), on “Teaching Trials and Triumphs”. How interesting an accident to have this inspiring female role model here on the eve of the International Women’s Day!

The message of her keynote was simple: there are four important ingredients in becoming a successful teacher:

confidence
feedback
passion, and
connection

To gain confidence, among other things, she advised us to ask for positive feedback from colleagues and coworkers (when deserved of course:-) and to actively pursue difficult challenges. Positive feedback energizes one to pursue more of the behaviors that led to the positive feedback in the first place; and accomplishing challenging goals inspires confidence to face professional challenges with more energy.

Students need feedback early and frequently on their performance and positive feedback is always better than negative feedback. On the flip side, teachers need student feedback. A great idea, which I will try to adopt in the future, is to distribute 3×5 cards at the end of each class asking students to respond to the question What I found most difficult today was … so that the next time the class meets the teacher can revisit the problem concepts and help the students catch up. And she also mentioned the story of a Mudd faculty who had the best day ever (as a teacher) when 100% of class “clicked” on the correct answer to a question she asked them! I can only imagine the excitement of having a whole class get it right together!

Then she related several stories of Mudd faculty demonstrating amazing passion for their job as teachers. I was terribly moved and inspired by the story of a young faculty member, with practically perfect teaching evaluations, who decided to spend his first sabbatical in a Los Angeles high school, whose students had consistently abysmal levels of math competency in standardized tests, teaching math! And this person, whose commitment I find terribly difficult to understand and impossible to espouse, spent the first six months failing (things were not working for him in the high school). But he did not give up and he stayed the course, to see things turn around in the seventh month after having gained the trust and respect of his students, through the recommendation of a trusted colleague and his own involvement with his students’ personal life.

But the most amazing story came towards the end when she talked about connection. She started with a story of a Mudd faculty who asks his linear algebra students to write an essay about what they learned in the course, relevant to their lives, because he believes that this is what our role as teachers is: to connect with our students’ lives. And he manages to inspire his students to think about how changes in perspective may lead to new ideas, just as changes in the chosen base of a space may lead to simplification of problems that seemed too big before. And then she talked about her personal involvement with a shy student who “was not happy” at Mudd, according to her parents. Apparently the parents came up to her, after she welcomed everyone to the family weekend, and told her that their daughter was not having a good experience at Mudd. And she met with this young girl and worked out a plan for how she could practice music and how she could work with another student (who was her mentor) and the girl’s life at Mudd turned around; and this girl, who started being terribly shy (too shy to practice saxophone because the music room was not 100% sound proof) brought to her a couple more students with problems (love-life problems among them, it turns out). And Klawe, the president, talked with them and advised them and connected with them, just as she had connected with the first shy girl, and just as the shy girl connected with her fellow students, and just as Klawe herself had connected with her PhD supervisor and learned form him how to be a researcher. And this last part made me see in my mind’s eye a long line of people – her supervisor, Klawe herself, the shy student, her fellow students – touching each other and having an impact on each other, changing each other’s lives in some significant manner.

And the fact that, Klawe, the Mudd president, can take the time and listen and think up solutions for the shyness and the love aches of these young students made me think that there is always time and always a place to connect with people. And in our privileged position of being teachers and being knowledgeable and having been there (where our students are) we have the opportunity and the duty to connect with them and with care and sensitivity and modesty try to add them to the chains of our lives.

Thank you Dr. Klawe!

email

Eleni Stroulia — Tue, 01 Mar 2011 03:00:42 +0000

I have failed… no question about it; two weeks gone by and no update; yet another resolution who did not stand up the test of time; but never mind, such is life; one simply has to recognize failure, concede the battle and keep trying, imagining a future victorious conclusion to the current war waged… (I am not actually taking myself that seriously, I just get carried away writing non-scientifically structured prose:-)

In that spirit, I decided to talk today about email.

I am going on a short vacation for a week and I am debating wether I should have access to email. It is interesting to note that this is a rare case of us taking a vacation that is not in our usual summer retreat to the old world and it is not associated with work-related travel (conference, meeting, …). There is no other motivation (see family, meet for a project) for this vacation except that to take a break as a family. This makes it feel quite decadent and self-indulgent, and terribly exciting. And somehow it brings to the foreground the question of email: there is no question about these other vacations: work-related travel implies the umbilical cord to the office email and work and so does the long vacation back in the old country (we would not be able to “afford” such long vacations if we were cutoff from the office). So here is this new “vacation-vacation exotic bird” which makes it seem possible, even required, that I should actually not have access to my office email. There is nothing much that can go terribly wrong in a week (especially when it is Reading Week), and I have been rather good at answering my email so nothing timely is pending (why do you think I have not been blogging?) and, worse comes to worst, people have my phone number so if anything terribly timely was pending someone would call me. So why am I thinking about it?

The funny thing is that I didn’t until a colleague mentioned to me in passing that I know you will not be able to do much about things since you will be away but you will be on email so you will know about everything, which made me think that

his expectation was indeed reasonable — this has been my mondus operandi for ever, so he can safely make this assumption; and
I did not want him to be right — why should I be aware of every small emergency and temporary tragedy and storm in a teapot back in the office when I could not actually be expected to respond to it?

So I started thinking about the possibility of not accessing email during my weekly vacation; and then I considered that I did not actually have to bring a laptop with me at all, so that I would not actually read/mark papers or edit proposals or work on my class or FB/twitter or blog.

And the novelty of this possibility just struck me!

And then I thought about my relationship with email has evolved over time:

I used to respond to email messages after I had made some progress towards the objective that the message was about, since more messages would usually be about some “todo”. Now I have a lot of messages that I skim and ignore; with filters much of this categorization can be done automatically. For the messages that I have to respond to, I usually generate a draft response which I conceptually equate with a “todo” and then file away. Many of them I try to pass on to other people who may be able to act on them (something like a hot-potato game…). For the ones I have to keep on my plate I make deadlines by when I must make some progress and I have developed a scheme (not explicit yet) for how behind I will allow myself to be on each particular task. Thus a good metric of how busy I am is the sum of messages in my Inbox and Drafts mail folders, plus some function of the pending todos in my task list (and how late/urgent they are).

So this is a perfect opportunity to validate my metric!

First a question of understanding the range of the metric values: I have been controlling this number to be ~20; this is my comfort zone, developed primarily based on my obsession to respond to my mail’s UI; but how bad would it become in a week if I did not control it on a daily basis? I am estimating ~500 messages
Second a question of validation: how bad is a big number? I have been operating under the assumption that 20-30 is OK and beyond that it is not. But when I see the big number after I come back, I am guessing that I may find that 500 can easily be brought down to 40 which would mean that 500 is not that bad after all.
This is more of a psychometric (I think this is the right word in this context but I am not sure) assessment: how will I feel when I see that big number of messages? stressed? worried? panicked? overwhelmed?

I have written up to this point of the post before my departure… I will complete it after I come back with the results of the experiment…

We are back! It was a wonderful vacation and I could seriously increase my word count if I were to report on what we did during this past week. But I will restrict myself to my original plan: I will only report on my reaction to my mailbox after I left it completely unattended for 8 days.

First let me just repeat it for the record: I did not read email for 8 days. I was tempted, I must admit; my husband had his laptop with him and his blackberry, and he was checking his messages. My daughter had her ipod and she did avail herself of free Internet towards the end of our trip at least. I used my husband’s laptop to find routes using googlemaps. So it is not lack of means that kept me true to my promise; it is simply my monumental strength of character:-) I am honestly quite proud of myself!

Now let me answer the three questions I set for myself before leaving.

I was really stressed when I switched on my laptop. I had visions of expired deadlines, funding agencies complaining, colleagues upset at my delinquency, students idling in mid-step waiting for me to tell them what next, children’s schools notifying me of piles of homework… I was truly scared.

I found out that I had 470 messages, which establishes the fact that I have a good grasp on my mail-traffic reality.

I worked through the day and reviewed everything.

I found out that

Today was the hard deadline for a short document due for publication; this was a duty that a colleague of mine was supposed to have completed but we are both responsible for it, so if I had been looking at my email, I would have done (or at least have felt obliged to do) it.
I had missed an opportunity to apply for some small funding to offset costs of undergraduate research assistants during the summer
Some actions were due soon-ish for a student to be paid and an account report to be generated and the account to be extended (all was done today).
Several submission notifications had come in; a mix of good news – bad news (what’s new?)
My students had taken care of several todos that, had I been checking email, I would have advised them on; it turns out, that would have not been necessary.
A colleague had taken care of a couple of conference-organization tasks for which we were co-responsible; I owe him some extra work in the future.
I had received a couple of todos from a committee of which I am a member; I took care of them today.
A bunch of meetings had been setup in my absence; I had to reschedule things in my calendar and a real problem has occurred due to the shifting which will have to be somehow addressed.
I got a reminder about a presentation I am supposed to give on Wednesday; I am sort of prepared for it and had I been reading email, I would have likely finished it off during the weekend; now I will have to squeeze some late-evening time tonight or tomorrow evening for it.
As I was working through my email, a really nice email came from a colleague complimenting me on my ABI profile; it was really heartwarming!
I got in touch with the colleague who, unwittingly, challenged me to not read email and we will meet on Friday to catch up with whatever has come up in the mean time; I am also meeting my assistant tomorrow in preparation for my Friday meeting.
A new proposal opportunity has arisen that matches some ideas that I have already been exploring with another group of colleagues and I need to work on it.
Some emergency work is needed on a collaborative proposal with which I am involved for the past year. A skype meeting has been setup for tomorrow at 6am.
Two more reviewing deadlines have been added to my list of todos.

In summary, I am a bit exposed with the potential of missing the hard deadline for the short publication but it is not a tragedy. Neither is the missed funding opportunity. Nothing terrible, not even really bad, has happened. I am relieved and, to my embarrassment, I must admit that I am a touch surprised also: I was really fearing that my weeklong absence might have some more important consequences, thus implicitly validating my practice of responding so fast. It turns out that a week-long delay is not long. Who knew?

Finally, I can proudly report that my 470 mailbox of this morning is tamed to ~45 (drafts and inbox messages) which shows that 45 is a good number but not that far away from 470; only about a day’s work. How’s that for calibration?

In the end, I am terribly happy I stayed out of email. I had an amazingly relaxing vacation, I read a couple of books, I had some memorably inane conversations with both my children and my mailbox is not threatening any more this evening. And, maybe, I may start a yet a different type of relationship with email, where I do not respond immediately, I let things sit for a week. It looks like mail does not go bad in a week…

My interview with the Anita Borg Institute

Eleni Stroulia — Mon, 28 Feb 2011 17:25:40 +0000

I was interviewed as a “Senior Technical Woman” by the Anita Borg Institute and the content of this profile can be found at http://anitaborg.org/news/archive/senior-technical-woman-profile-eleni-stroulia-professor-and-nsercicore-industrial-research-chair-university-of-alberta/.

Where a “great success” gets tainted…

Eleni Stroulia — Thu, 03 Feb 2011 03:47:13 +0000

I did not want to post this entry, for many reasons.

I am embarrassed to admit that I am not a good teacher.
I am terribly disappointed to be confronted with this failure, just after the “high” of the publicity around my City-of-Edmonton inspired project in my CMPUT course.
I am completely frustrated by the fact that what I thought was a good (in fact a better-than-good) course may end up in my “failures” column.

So I was not going to post it, definitely not.

And then, I decided to join the ranks of the ones who come out with embarrassing stories about themselves, in the hopes that their stories may be useful to others who are facing similar situations. And so here I go and I am posting this entry.

Last Friday, I found in my mailbox my teaching evaluations for my course last term. They were not-quite-abysmal but they were definitely, undoubtedly, undeniably bad. If the world was black and white, these evaluations would be black (or white in cultures where white is a color of mourning).

Now, I should also come clean with the fact that I am not an award-winning teacher (at least not at the undergraduate level) but these evaluations were quite below what I have come to expect from me. And the clear message (in fact the only written comment on the back of the collection of “agree/disagree” questions) was that the project was too hard. And the fact is that the project was not really too hard, definitely not harder than the projects usually done in this course in past years. And the only explanation that I am left with is that my students disliked the fact that the project was “real” and saw this to be too hard. Maybe I am oversimplifying but, no matter whether the project was the reason why my evaluations are bad or not, the truth is that the students did not like the project; they disliked it more than students generally dislike the project in this course; so in the end, I am having to attribute the strong dislike of the students for the project to the only feature that distinquished this project from the projects of past years: its realism. And that frustrates me … a lot. And, I am not sure what I will do next time I have to teach this course, and I am guessing it depends on when the next time will be and whether I will have forgotten the sting of this experience by then…

On the importance of UCOSP

Eleni Stroulia — Mon, 24 Jan 2011 22:42:13 +0000

This past weekend I hosted the UCOSP code sprint at the University of Alberta. About 40 students and 7 project mentors came here for an intensive weekend-long session of software development.

UCOSP – the Undergraduate Capstone Open-Source Project – is a distributed software-engineering course that brings together undergraduate students across Canada (and sometimes North America) to work on open-source projects.

I have described the nuts-and-bolts of UCOSP several times to different people with different purposes, so I can easily give a short description of “how UCOSP works”, since I am hoping that some readers may consider participating.

From an administrative point of view, UCOSP is managed by a steering committee of three, Michelle Craig and Karen Reid at the University of Toronto and Eleni Stroulia at the University of Alberta, with support from a part-time administrator. It runs under the auspices of the Canadian Computer-Science Department Chairs.

Each semester, since the Fall term of 2008, a few (between five and ten) open-source projects are solicited and selected to join the UCOSP. Projects that participate in UCOSP should

be open source,
have an existing user community, and
have a person willing to act as a mentor and team lead for a group of students.

At the same time, through software-engineering faculty in Universities across Canada, senior students are solicited to participate. These students register to related courses in their home institutions, usually independent-studies or special-project courses, with a supervising faculty. The steering committee associates students with projects, based on their preferences and background. During the term, the students work in the context of these distributed teams under the guidance of the project mentor, who, in the end, comments on each individual student’s work and performance and assigns a “grade” which, then, is submitted to their home institution by home supervising faculty.

In the beginning of each semester, UCOSP facilitates a “code sprint” week-end, where the students enrolled in the program travel to a central location and work on their projects with fellow team members and their project mentors. And this time, the sprint was at my home.

So now that I have the descriptive details out of the way, let me proceed to the more interesting part of the blog, and let me explain my position on why I think this is a terribly important, interesting and rewarding activity.

First off, on “why this is important”, I have to say that this is as close as we can get to the proverbial “real world”, in teaching software engineering. And making it real is terribly important from a pedagogical perspective. I am working with many colleagues in health-science disciplines who, at this point in time, are seeing a shift in their pedagogy model, from curriculum-based to competence-based. As a result, instead of defining the “required body of knowledge”, educators are defining “professional competencies”; correspondingly, instead of assessing students through traditional examinations designed to cover this or that body of knowledge, educators are turning to simulation-based methods for training and assessment, so that students should not have to demonstrate knowledge of facts and procedures anymore but rather their ability to bring this knowledge to bear in scenarios simulating the situations where this knowledge is relevant in real practice. I believe we (software-engineering educators) should be doing the same, namely develop simulation of the real practice, which is what UCOSP essentially is. This is the only means to actually train people to become competent in

dealing with projects whose lifecycle does not coincide with the student project (all of our UCOSP projects exist outside UCOSP and some have long lifecycles and large developer teams within which the UCOSP student teams work),
collaborating with team members (without relying on the bonds that usually come with belonging in the same peer group or class cohort),
managing their personal agenda and synchronizing it with that of the project (without relying on well-defined deadlines for submissions that come with the well-defined well-scoped projects of typical courses and similar typical loads across the team members),
dealing with unknown tools and languages that the project comes with (which is usually unheard of in projects of courses with well-thought out dependencies on prerequisite courses), and
working across time zones (Canada has a special advantage in this dimension).

Second, on the “why is this interesting” question, I have to argue for its variety. The scope of software systems that are being developed by UCOSP projects is astounding. This term, we have a mobile application (on the Android platform) for biological monitoring applications, a couple of video recording/streaming/sharing systems, and two web-based tools. The students get the opportunity to explore conceptual and technical problems and technologies that cannot possibly be part of any four-year, or even five-year, undergraduate program. Clearly, it cannot be the objective of an undergraduate program to teach students all technologies, especially in a field so fast as computer science. Instead, it is our objective to teach students how to learn; and UCOSP gives them the ability to practice this “learning” skill and develop this competence, while at the same time adding “knowledge facts” on their CVs, which may make them more appealing to an employer down the road.

Finally, “this is rewarding” because it is actually quite fun! It is a bit of stress, matchmaking students and projects, aligning calendars and deadlines across schools, getting feedback on time to students and home-institution faculty supervisors, and – generally speaking – making sure that a standard (in terms of amount and quality) work is being done by each individual student in each individual project. On the other hand, students love it and appreciate the opportunity and the sprint itself is a blast! In our building we have a open atrium area and from the third floor I could see inside several breakout rooms on the second floor, where UCOSP teams were working. I could see silent teams “hacking”, I could see teams drawing on whiteboards, I could see teams skyping with some remote mentors, I could see teams laughing at jokes! The intensity of their working faces, the energy of their thinking “fights”, and the merriness of their fooling around was so exciting and so optimistic that I am charged for at least a week of drudgery… but I have not drudgery in my future so will bank it for the future!

What makes a good project for a software-engineering course?

Eleni Stroulia — Mon, 17 Jan 2011 05:34:48 +0000

I, and, I know, many of my colleagues too, fret over designing our project-based courses. Courses in the computing-science sub-disciplines within the generally construed “systems/applications” area, like databases, software engineering, operating systems and architecture, frequently use projects.

I am a strong believer in learning-by-doing (the fundamental principle of constructivist pedagogical theories) and learning in teams of peers and I have never shied away from taking risks in leading complex, open-ended projects, even in undergraduate software-engineering courses. In these courses, most students learn to analyze complexity and conquer it through good software design, effective project management and teamwork, and solid development. Many (I like to think most) students thrive in these projects, in spite of the original uncertainty and fear that it is too much and that I have unreasonable expectations, Some do not; they get flustered and frustrated usually when the team dynamics t=do not work.

So here are a few things that I have explored in the past. In Fall 2005, a CMPUT410 student developed XBook, a web-based application for UoA students to buy and sell used textbooks from previous terms while registering for subsequent courses. This student actually chose the application himself since he found my project specification “boring” and in the end, through his connections with the UoA Student Union, he arranged to have the application integrated with the Beartracks registration system. More recently, in the Winter term of 2010, I gave my CMPUT301 students the task of developing a web-based visualization interface for the Orlando project. The Orlando people gave me access to a data set, and then proceeded to simplify it about four times at my request. The data set included was a set of XML-annotated documents about English poetesses. The thing I remember the most about this project was the fact that our notions of well behaved XML were soon thrown outside the window: the XML tags were well formed of course, but the schema was terribly lax and since the tags had been added by editors they were terribly inconsistent, frequently missing attributes and internal elements. In the end, the successful teams identified interesting data nuggets and, around them, they developed really useful and inventive visualizations. And of course, this past Fall 2010, my CMPUT301 students developed an application for Edmonton visitors based on City-of-Edmonton open data. And of course, I have also been several times a mentor for UCOSP, supervising distributed undergraduate cross-Canada teams, working on open-source projects.

Recently, I specified a set of projects for my graduate course. I used to leave the project specification in graduate courses to my students. This sometimes worked excellently, when students were interested in the area and has a specific research problem to explore in mind. In far too many cases, however, student-designed projects ended up being weak since they did not have a good intuition for what is important in my area of research (which my graduate projects cover) and, I, in spite of my good intent, would frequently fail to tease out the interesting software-engineering challenges in their envisioned projects.

So this year I am trying something else: I am making up the projects specifications, and I am “negotiating” with my students changes and variations that may make them more interesting to them, without compromising the software-engineering content of the project. I must admit that this was an idea that came from another colleague, which intrigued me enough to try it. And as I am trying it, I have been thinking what makes a software-engineering project a good opportunity for learning. I am definitely not sure that I can completely answer this one but I think good projects have to meet at least the following requirements.

They have to come with constraints about the nature of their implementation: today, there is a huge variety of technologies and, unless a few reasonable choices are given as a starting point to the students, they may end up making a misleading choice. In the end, technology is a tool and some are definitely inappropriate, I think that identifying a few possible good choices is essential.
They have to be of substantial complexity, which can be understood and organized in layers. “Easier” projects get completed but may not be sufficient learning vehicles. Students, definitely the good ones, get excited by the challenge of complexity and, as they proceed to manage it through architectural design, they learn some important lessons.
They also have to be relevant; someone must have a vested interested in the project’s success, besides the student that is. A grade is never motivating enough. In my graduate course this year, all projects are defined in consultation with clients who are actually interested in meeting with the students and using their products. This co-creation process, where the potential consumer informs and elaborates the needs and the software professional translates the stated needs into designs and systems, is terribly fulfilling. And although I appreciate the potential elegance of a project that has been conceived, designed and developed by a single agent, the external validation that comes from a “satisfied customer” is priceless to me.

So I am excited to see what will come out of this batch! And I will report some time in May:-)

God is in the Detail

Eleni Stroulia — Mon, 10 Jan 2011 03:56:12 +0000

I have had two interesting (and rather intense) professional experiences recently, which made me say to myself a few times “the Devil is in the Details”. And I wanted to reflect (i.e., think aloud) upon these experiences and so I went and looked at Wikipedia where the expression comes from. And there, I found that the ‘original’ was “God is in the Detail”, which is much closer to what I actually have been thinking – thus the origin of my title.

The first was around the development of a rather complex software system under rather extreme time constraints and with a very public development/testing process: the system, a web-based tool, supports three layers of users and each layer can only start working as the “previous” layer has completed their activities. Within each layer, a long-ish workflow is to be supported (longer for the first layer, simpler for the last). Given the tight timeline, the system subsequent functionalities (i.e., later workflows) were developed as the ‘early’ functionalities (layer one, first workflow steps) were being used. My role in the process was to “manage” the small developer team (of two) and to translate the client requirements into design and implementation decisions, so that reasonably good code might be produced to meet the functionality required in the most “inexpensive” manner. At the esame time, I was handling (as much as possible) the user help center, to give the developers time to deal with development and debugging as necessary. To top this off, the timeline of the project overlapped with the Christmas break! My team did not have a long break, meedless to say:-)

The other experience has been the design of my graduate course, about to start (Tuesday this coming week is the first meeting). My course is, generally conceived, on “software engineering”. Its specific focus is on system integration on the web, frequently involving reengineering of existing resources to make them fit in the integrated system, using web-service technologies, while being aware of the human ecosystem around the system under development. The important thing to note here is that the systems we are concerned with are systems used for supporting human-intensive processes and services, so there is lots to be aware of when we talk about “the human ecosystem”. This is the way I perceive my area of research, branded under the term “Services Science” and “Service Systems”. So I started writing my course outline, and that went well. There are tons of interesting problems in the area and I am excited about them, so clearly I can describe them and I am sure the students reading the description will just “see” how terribly exciting the field is and how fulfilling and fun it would be to work in it! And then I started describing the course-evaluation process, which of course involves projects; and then I started describing my projects; and it went really well throughout the motivation paragraph (all my projects are motivated by real needs of real clients, i.e., researchers who are working with systems that do not work and envision their new variants), and the general plan paragraph, but then I started working on project-specific deliverables and this is where the muse abandoned me…

In both cases, I realized that “Details” are important:

users are affected by how exactly reports are formatted and where buttons are placed; if these decisions are wrong, then people are unhappy and systems are unusable
my team is really good! they are pretty darn amazing in fact! but bugs somehow happen (just like other “things happen”); and this time, we had many really “good bugs”; you know, the ones that depend on a particular setting of a five-year old browser; or the ones caused by extra spaces that make a careless matching function fail; or the ones that five fields still manages to generate colliding keys for one unfortunate user…
some of the workflow steps ended up making incorrect assumptions about what the users actually knew; a fact the client specifying the requirements did not necessarily know and neither, of course, did we, but we discovered as users starting attempting to enact said workflow
in the context of my course, the details of what I actually envision as “deliverables” are difficult to pin down; these are research projects after all! but they are also course deliverables, the same way that the system whose development I had to manage had specifications, which we were “almost” meeting as we were fielding user questions and hunting down obscure bugs reported by individual users

So God (and accomplishment and perfection) is in the detail, which (it just dawned on me, as I was writing this post) is the same idea as the 80/20 rule (80% of your accomplishments come from 20% of your task list). It is this last 20% that needs to be accomplished, the part that will require the 80% of our effort, that makes the task complete! It is this missing 20% that may cause the “failure” label to be affixed to our project or may generate comments about “the objectives of the course were not clear” feedback to be collected about my course. It is this 80% of effort that will enable perfection.

And sometimes perfection is impossible… I really believe that my software-project timeline was quite impossible; and, by procrastinating on my course specification, I made this timeline impossible too:-) But through this experience, I became painfully and starkly aware of the distinction. Especially in these fields where there is no long chain separating us from the “client” who “validates” our effort. In both these cases, the client – namely the users of our software and the students in my course – are so close, practically “in my face”. And this is not generally the case in our job as academics; we are, in general, removed from the hard validation step: when submitting a paper the acceptance/rejection decision is really a judgement about whether the work is “good enough” (or, even worse, in the case of conferences “better than the competition”) not about whether it is actually “good”. And, moreover, it comes from a faceless “committee” not from a user or student with a name and a face! And it is easy to forget the distinction between “good enough” vs. “good”, between “80% done” vs. “done” and miss the importance of the details.

And, I do believe, that in some cases in may not matter: “good enough” is frequently good enough! But there are cases where it does matter; where what is needed is “good” without qualifications, without footnotes. No matter what though, perfection is, and will always be, in the detail!