Tuesday, June 30, 2015

Collaborate with Mexican software engineering students to solve real problems

For the last few years Dave Patterson and I have been successful in running CS169 Software Engineering with student projects focused on nonprofits.  Recent customers have included CityDogShare, UC Berkeley Food Pantry, Khan Academy Myanmar, CalCentral, the Palo Alto Veterans Hospital, and more.
Next Spring we want to try something new.
My colleague Prof. Juan Carlos Lavariega from Instituto Tecnológico de Monterrey, Mexico ("el Tec") would like a couple of teams of his best software engineering students to collaborate with a couple of teams of our best software engineering students, to work with a nonprofit on problems relevant to both the US and Latin America. Think immigration, cultural assimilation, workers' rights, cultural exchange.
We are looking for a small number of students passionate about this area to help put together this effort.
The goal is to create this collaboration from a subset of the student teams in my CS169 (Spring 2016) and a subset of Prof. Lavariega's Spring 2016 capstone project course teams. On the Berkeley side, this would mean that those teams' CS169 projects would be in collaboration with the Tec students.
Everyone knows that nothing really happens in academia without students leading it, so this is my call for interest. You'd help identify nonprofits and projects, help coordinate the teams, and ideally be part of one yourself (so I'm particularly interested in people who are planning to take CS169 in Spring, and this would get you priority admission if it's overenrolled). There would be some preparatory coordination activities during Fall.
Email me if you're interested and let's further Berkeley's tradition of doing well by doing good.

Friday, June 19, 2015

The Baker coffin is a metaphor

A couple of weeks ago I got to attend my 25th reunion (MIT Class of 1990). As always for these events, the highlight for me was seeing/reconnecting with my former housemates from Baker House, the most awesome dorm/living group on campus. Both for nostalgia's sake and to save money, I opted to stay in a room at Baker during the reunion. (544—Fifth East—if it matters to you.)  This was the popular "coffin" configuration, the smallest of three different types of single rooms available in Baker.


(Ironically, I never had a coffin when I lived there; I lived in a quad freshman year, two weird-shaped back singles 607 and 608 which were removed when the Institute remodeled Baker in 1997 since they weren't part of the original design, and 331—a pie—senior year.)

My friend Nikki Skinner was also staying in Baker during the reunion (in a triple, since she brought her kids), and when she came by to see my coffin accommodations, she commented to me, "It's hard to believe that at one time we were able to fit our entire lives inside one of these."

On the way home I realized how metaphorical that observation was.

A 25th reunion means the number of years since leaving Baker House exceeded my age at the time I entered Baker House.  That's some sort of inflection point to adulthood, I think.  And while life is really good, it's also definitely more complicated now.

A "coffin" was large enough not only for our worldly goods (such as they were), but also, metaphorically, our emotional and intellectual concerns.  For most of us back then, the biggest issues we had to deal with were grades, deciding what social opportunities to pursue over the coming weekend, and whether to do the "walk of shame" late at night or just wait and deal with it in the morning.  Surely we had personal matters to deal with as well, some of which may even have seemed at the time to have some gravitas; but speaking for myself, they seem pretty trivial from this distance, compared with what most of us have to deal with as grownups.

So yes, it is hard to believe that there was a time when our lives fit into a Baker House coffin, physically and metaphysically.  That was the privilege of that time, and it's why I always feel warm and fuzzy when I remember that era and the friends I made, who I still fly cross-country to see.

As Nikki also said upon arriving in her Baker House accommodations for the reunion: "We're here...I want to move back!"  I see her point.  Who's with us?

Baker friends: here's a few more photos from the event.  It was wonderful to see you all.

Sunday, February 8, 2015

Where's the low-cost Munchery?

A friend just invited me to try Munchery: It's a delivery-only service in which noted chefs prepare a limited and healthful menu each day, and you can get stuff delivered within a roughly 1-hour window of uncertainty if you're in their delivery area. Your credit card is on file, so payment is automatic when you order. It's convenient when you have an irregular work schedule, and I'll almost certainly make healthier choices than if I default to ordering pizza or Chinese food when I get home late and too tired to cook. I'm excited to try it out.

But it is also symptomatic of the too-many startups chasing the same customer demographic. Wouldn't it be great if there was a Munchery for people who can't afford to spend $12 on dinner? (Not that $12 is unreasonable for delivery of what they offer, but the reality is most people can't afford to spend that much on dinner more than once in a while, and many cannot afford it ever, or barely ever.)

There's been a fair amount of controversy over the connection among income level, lack of access to healthy food (living in so-called "food deserts"), and obesity/metabolic syndrome. But whether the problem is people making bad choices because they have no other choices, because they're underinformed, or because they lack the time or skill to do their own preparation, wouldn't it be great if there was an economically viable model similar to Munchery but at a different price point? Maybe the entrees wouldn't be prepared by up-and-coming star chefs; maybe the number of daily selections would be more limited; maybe the delivery window would be wider; but the meals would consist of sane-sized portions of minimally-processed ingredients prepared in a way that goes easy on sodium, added sugar, and fat. The vegetables would not necessarily need to be organically raised, and the cows would not necessarily have to be range-fed and massaged, but I'm sure there is room for improvement over what many families eat now. I can't help but wonder if a startup could find a way to do this at a price point that is reasonable and competitive, despite the federal government's insistence on "fighting obesity" on the one hand while subsidizing the broken agri-factory system that makes fast food possible on the other hand. You could even imagine that such an outfit is set up to redeem through nutrition-benefits programs (CalFresh, Food Stamps, and so on).

Has anyone done the economics? It seems there'd be a large market, and you'd be doing society a good turn. Berkeley has startup competitions every year; I'm waiting for a round of startups like the one above, that target the unexotic underclass.

Tuesday, February 3, 2015

Double-teaming on same customer app?

This semester there's once again apparently infinite demand for my  (yes, the one that goes with the book and MOOC).


We capped enrollment at 240, but we may end up with less than 40 customers (we target 6-person teams).


So, suppose two teams work simultaneously on different designs/implementations of the same customer-facing app. What pedagogical benefits might we derive from that? That’s where I want your opinion.


The project includes 4 two-week iterations, each including both a customer meeting and a meeting with a TA. Before iteration 1, the teams have initial meetings with the customer to understand the business need and do some lo-fi UI mockups and user stories for the first few features.

After the fourth iteration we have a project fair where teams present posters about their work.


Let’s call two teams working on the same customer app the Blue and Gold teams for that app, so I can describe our proposals:


Option 1: Team rotations.



  • Iteration 1: Each pair of teams of six works on initial set of stories agreed upon during initial customer meetings.

  • Iteration 2: Two people from the Blue team will change places with two from Gold team. The remaining 4 Blues will have the job of bringing the two Golds up to speed (via pairing, reviewing design documents, etc) so that the Golds can contribute, and vice versa. After the two-week "visit", the Blue visitors will report on how easy it was to come up to speed (both how helpful the Gold "hosts" were and how clean the code was, allowing them to understand the code rapidly), and the Golds will report on how good of team players the Blues were; and vice versa.

  • Iterations 3, 4: two other people change places, so that after 4 iterations, everyone will have been a visitor for 1 iteration but every team will always have 2/3 of its "permanent" members working.

  • (Variation: iterations 1 and 4 are the complete team; iterations 2 and 3 have three team members swapping places, thereby forcing a change in pair-programming behaviors as well.)


Pros:



  • direct experience coming up to speed on and adding value to "legacy" code, which would allow us to eliminate the separate legacy code homework (in which people add features to the open-source blog engine Typo; it’s a decent assignment but certainly not as realistic as this!)

  • direct experience onboarding new people

  • possible motivation to make your code cleaner and better documented knowing that someone outside your team may be looking at it next week


Cons:



  • more time involved for customer

  • possible drift between Blue and Gold which may be harder for customer to keep track of

  • may interfere with "team spirit"

  • may be too much of a discontinuity so that it interferes with project progress.


Option 2: Design/code reviews.


One or more times during the 4 iterations, Blue will review Gold's design and code according to a detailed rubric. Gold's project grade will depend in part on the reviews' comments and Blue's will depend in part on Gold's assessment of the thoroughness and helpfulness of the reviews (for example, can Gold identify one or more things they'll do differently or refactor based on the review).


Pros:



  • no logistical issues

  • makes design/code review a first-class citizen (though we would have code review be part of Option 1 above as well)

  • no additional work for customer

  • avoids possible project progress issues that could arise from team-swapping plan.


Cons:



  • less "skin in game" when reviewing code than when asked to add value to it

  • forgoes experience of modifying (vs just understanding) legacy code


Option 3: your great idea here.


How else can we turn the "bug" (not enough projects) into a pedagogical feature? Comment here, or if you prefer, email me!