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!