Background. CS 169 is Berkeley’s upper-division (seniors and some juniors) software engineering course.  The way it’s taught varies widely depending on the instructor. This post describes how I teach it, often with the help of Dave Patterson and recently also Koushik Sen.  It’s not a required class in the major, but rather one of several classes that satisfies specific requirements such as a design project, technical communication, etc.

Prerequisites. This is the only undergrad course at Berkeley that claims to address the topic of Software Engineering.  As such, it’s ambitious and fast-paced, with 5 1-week programming assignments, 5 quizzes, and a significant team project with an external customer, all in a single 14-week semester.  Students should be comfortable with at least 1 other language and with basic programming concepts such as object orientation, classes and inheritance, recursion, and higher-order functions.  Prior to this course, Berkeley CS students take CS61A Structure & Interpretation of Computer Programs, which introduces the four major programming paradigms (until recently using Abelson & Sussman’s awesome “wizard book“,now using Python); CS61B Data Structures using Java; and (usually) CS61C Great Ideas in Computer Architecture (aka Machine Structures), using C, MIPS assembly, and more Java (for a Hadoop assignment).

History. While working on the RAD Lab project (2006-2011), we needed SaaS apps to show off our machine-learning-based technology for automating various aspects of cloud operations.  Since no Berkeley course taught SaaS, we created an informal seminar course in 2007 to bootstrap a cohort of undergraduates to create showcase apps using Rails.  It was so popular that we offered it again, increasing the focus on TDD and good software practices, when our colleague Paul Hilfinger observed that we were well on the way to teaching the basics of Software Engineering in a format that students were enthusiastic about, so why not go all-out and teach CS 169 this way?  We agreed, and we did a “dry run” of the beefed-up course in Fall 2009, debugged it, and offered the “SaaS version” of CS 169 for the first time in Fall 2010.  Enrollments have been increasing by nearly 50% per offering.

Practices taught and course format. The course teaches software engineering techniques based on the Software Engineering Body of Knowledge (SWEBOK) using SaaS+Agile+cloud as the vehicle and Rails as the framework.  Our recent CACM article explains why we believe our choices bridge the gap between what academics believe should be covered in software engineering courses and what industry wants to see in graduates of those programs.  (Contrary to what one might expect, leading software companies do not want us to become trade schools teaching specific tools, languages or frameworks; they want skills that transcend these, including dealing with legacy code and working in a team serving a nontechnical customer.)  We chose Rails because it has the best testing and code-grooming tools and its developer community places high value on beautiful code and thorough testing.  There are two lectures and one small-section meeting (~30-40 students) per week, weekly programming assignments, bi-weekly short-answer quizzes, no “big” midterm or final exam, and a 6 to 8 week course project.  We are experimenting with pair programming as well.

Course project. “Two-pizza” teams of 4-6 students work with real external customers—some nonprofits, some on-campus units, some others—to develop and refine a prototype that solves a real customer problem.  Students meet with customers, use lo-fi mockups and user stories to agree on goals, use BDD and TDD to deliver and deploy new functionality to the public cloud during each of four 2-week iterations, and use Pivotal Tracker to estimate progress.  At the end of the course, students present their work in a poster/demo session attended by course staff, the external customers, and invited guests such as industry practitioners and VCs.  Many students reported that their customers were so delighted that they were trying to hire the students to continue the work over the summer.  Two projects from Spring’12 were already deployed in production with real users by the time the poster was presented.

(Coming soon: a partial list of short video screencasts highlighting representative projects and interviewing the customers involved with them.)

Scalable grading. Given the growth in popularity of the course and CS courses in general here, we had already been thinking of ways to scale the grading by repurposing testing and code grooming tools such as RSpec, Cucumber, Mechanize, reek, flog/flay, and Webdriver (Selenium) both to assess correctness of student code at a fine grain and give nontrivial feedback on code quality.  When we agreed to offer the first 5 weeks of the course as a massive open online course in Feb/Mar 2012, it forced the issue and made us sit down and write the autograders.  Of course, these are no substitute for actual interaction with an instructor; indeed, the autograders have freed up our teaching staff to focus on creating additional review material and holding design meetings.  (If you’re an instructor interested in participating in our in-classroom beta program, we’ll even run the autograders for you.)

Book. Modern SaaS touches on many areas, including datacenter computing, databases, OO programming, testing, debugging, legacy code, and many more.  While there are many great (and not-so-great) books and online resources on each of these topics, a reading list cobbled together from them is impractical, lacks a through-narrative, and is very hard to get students to take seriously.  We finally decided in early 2011 to create our own book that would cover the “most important 10%” of each topic and weave them together in a way that both made sense for a one-semester (or shorter) course and allow instructors with less time or a less-sophisticated audience to select subsets of material appropriate for their needs.  We decided very early to self-publish to keep the price low (currently $10 ebook/$20 print book).  Engineering Long-Lasting Software: An Agile Approach Using SaaS & Cloud Computing is now in its third alpha draft, and we expect it to be content-complete by this summer.

We’ve been busily debugging the homeworks, autograder and other technology at Berkeley, hoping it won’t melt down when lots more students take it.

But surprisingly, those aren’t the things that made my heart skip a few beats the last couple of weeks.

It turns out that when you have 60,000 people enrolled, if 0.1% of them experience a problem, you’ll immediately get 60 identical emails.  And these people are resourceful: they simply Googled the names of the instructors and sent email to our personal email accounts at Berkeley.  Here are some problems those people had in the last couple of weeks.

Fun event #1: Kindle ebook disappears from Amazon.com

About 2 weeks ago, the Kindle ebook mysteriously disappeared from the Kindle store, showing “currently unavailable” if you visited its page.

• We received no email warning before this happened.
• No further explanation was provided on the Author/Publisher dashboard as to why it occurred.  In fact, according to the dashboard, our ebook was “live” and available for sale.
• There was no way to appeal except by sending email via the Amazon KDP “author support” form; we had done this in the past and it takes 3-4 days to get a response to such requests.  No phone number is provided for author support.  (In contrast, CreateSpace, the print-on-demand company handling the print version that ironically is owned by Amazon now, has excellent telephone support.)
• Desperate, we used our academic connections to the highest levels of Amazon to get this looked at.
• We learned that there was a formatting issue with our ebook, and apparently when enough customers complain about that, the ebook is pulled.  Amazon’s system was supposed to have sent us an email notification of the problem to give us a chance to fix it, but due to a bug on their end, that email never got sent.
• Once the escalation occurred, everything was resolved within a day; but if we hadn’t had higher-up contacts at Amazon, we would have been screwed.

Fun event #2: saasbook.info mysteriously shut down for “terms of service violations”

Last week the book’s website, hosted on Google Sites, was mysteriously shut off by Google “for terms of service violations”.  This was puzzling and panicking, since we had just announced to 57,000 students that they could start perusing the book, and this site was where they were directed to go to get it.  Plus, having the students see “This site has been taken down for TOS violations” made it sound like we were fronting pornography or running a link redirector or something equally questionable.

The scenario was eerily similar to the Amazon problem:

• We received no email warning before this happened.
• No further explanation was provided on our Google Sites dashboard as to why it occurred.
• There was no way to appeal (except to click a single button that said “Appeal” with no other explanation).
• Desperate, we used our academic connections to the highest levels of Google to get this looked at.
• We learned that our site had been mistakenly manually misclassified as spam—which was puzzling for any number of reasons).
• Once the escalation occurred, everything was resolved within a day; but if we hadn’t had higher-up contacts at Google, we would have been screwed.

Fun event #3: courseware VM can’t be downloaded or uploaded

We had numerous complaints from people unable to download the courseware VM via our AppEngine front end, and our TA’s were having trouble uploading the image file. Apparently, there were two problems.  One is that Google’s blobstore sometimes sporadically throws an error that doesn’t occur till the end of the upload, i.e. after spending 10 minutes uploading a 1.7GB file.  The error occurs inside one of the wrappers for the BlobStore API, and doesn’t get logged or rescued, so even though we have tech support at Google for this, there’s no way to show them what error occurred.  We ultimately transmitted the VM image file to a colleague at Google who was able to upload it via Google’s intranet.  If we hadn’t had this higher-up contact at Google, we would have been screwed.  (See a pattern yet?)

The other problem seems to occur for people whose Internet service is anemic.  The downloads get throttled and take so long that their ISP’s time out their TCP connection. We’re going to recommend to these folks that they use a download manager; one of the users discovered by accident that deeplinking to the AppEngine app works just fine.

We’re also going to torrent the file, and we’ve  provided an alternative to downloading a VM image—we created an Amazon Machine Image that can be used on EC2.  (A shout out to Yarko Tymciurak in the Chicago area who got us started on this!)  However, for students who don’t want to pay for EC2 usage, the free “micro” tier is just barely adequate to do this work—the CPU pins right away when running tests or builds.

Fun event #4: Kindle ebook updating doesn’t quite work the way we were told

An early and influential factor in our decision to focus heavily on an ebook was that we were assured that if we made significant changes to the ebook, we’d be able to quickly push them out to students by notifying Kindle author support, which would then notify purchasers of the ebook that they had the option of re-downloading a newer version.

This is partly true.  We tried this process last week, since we did in fact fix a bunch of typos and formatting issues reported during the first 4 weeks of the Berkeley course.  It took 3 days for us to get a response from Kindle author support.  The response was that we should submit detailed information about what changes were made, and “within 2 weeks” they’d make a decision of how and whether to handle our request to push the update.  So much for instant update.  They seemed to imply, though, that there was a way they could enable students to request a re-download if we notified students that one was available, so we’re going to try to go that route.  I hope this works, since we expect at least one more rev of the ebook by the end of the online course and then another before the planned summer offering of the online course.

Fun event #5: our Kindle book price is apparently just a suggested price

We had various ebook purchasers complain that although our own Web site says the ebook costs US$9.99, Amazon was displaying a higher price for them, as much as 27% higher in some cases.

It turns out that Amazon can, at their discretion, charge more for your ebook in certain territories “where their operating costs are higher”.  So it was with chagrin that we read these emails, given that we had agonized over the price a fair amount and ultimately decided to keep it below $10.

It also turns out that Amazon can, at their discretion, charge less for your ebook if they’re doing it to price-match a competitor or for other promotional purposes.

But things are rolling along anyway

But the news isn’t all bad.  Kindle ebooks are outselling print books by more than 4 to 1.  We’ve even gotten complaints that people in Indonesia can’t buy the ebook (which is unfortunate, but it’s humbling that we have followers that far away).

We can’t tell how many people are buying both the print book and ebook, since we haven’t been able to work out bundling. (Though we are working on it.)  We also can’t tell how many additional people, if any, have downloaded the free Kindle sample (which roughly corresponds to the first chapter of the book, therefore the first week of class) and may be considering buying the full version later.

We have a very  nice iBooks version about to come out with interactive self-assessment questions and screencasts built right in, and we will probably do a Nook/ePub version for people with non-Kindle ebook devices (though that’s a lower priority).

Overall, it’s been a major learning experience so far trying to reach this many people.  Next week comes the real test…

Besides being one of the most poignant documentaries I’ve seen in some time, it drove home to me how ingrained is our instinct as a species to tell a story.  Here’s a group of people who, in general, have serious trouble driving a car, playing an instrument, writing poetry, doing athletics… yet they relish the opportunity to tell a story, and they rise to the challenge.

Tonia pointed out that two other behaviors we saw in the rehearsals—singing and laughing—also cut across levels of mental ability.

So there it is.  Telling a story, singing, and laughing—the universal constants.  I knew there was a reason I did this theater thing.

And if you harbor even the least bit of idealism about how theater can affect people, watching Yellow Brick Road will be an hour well spent.

“… and your little dog, too!”

The old Star Trek episodes are wonderful morality tales. And hey, it’s not their fault that special effects in the late 60’s weren’t very advanced, and the effects budget per episode was apparently about $50.

I smile at the cheesy effects and appreciate the storyline, but I can’t help but enumerate a few effects things that particularly tickle me as a computer scientist.  I’m blogging these so that someone blogging in 2020 can smile at my comments, and all while giving the original Star Trek the largest possible credit for couching great stories in something that the 60’s thought the future would look like (remember, the final Star Trek episodes were taped a full 2 years before the moon landing):

1. The analog dials on the ship’s computers
2. Computers with AI-complete speech recognition, but synthesized voices that sound terrible
3. Computers that actually emit smoke when they fail
4. Audio communications that fail as analog radio would (analog static and high-Q artifacts, not digital dropouts)
5. Video that fails by getting snow or loss of analog sync (I still can’t believe people used to do all this with analog signals.  That is some studly engineering.)
6. “Video” displays that are clearly posters
7. Mechanical switches for controlling solid-state devices, including the transporter and the “computer”
8. Printers that make mechanical noise when they print (like dot matrix and band printers)
9. The presence of physical books rather than ebooksat various official proceedings
10. Avionics that fail by bursting into flame, yet are apparently repairable at the board or component level

Note that a great many of these effects were actually accurate when viewed from the standpoint of the first computers in spaceflight—see Computers In Spaceflight: The NASA Experience for a most excellent overview and retrospective.

Amazon’s Kindle has a pretty good selection, and they’re at least priced intelligently (~50% of print edition), but you can’t view PDF documents on it. Yes, I know about the “converter”. It doesn’t process tables or figures, making it useless for any technical PDF’s, which for me is most PDF’s. The CyBook uses the Mobipocket DRM format, which is sold by dozens of half-assed retailers whose selection and reputation aren’t even a fraction of Amazon’s and whose pricing is stupid—the ebook costs the same as the print edition, and I can’t even donate it to my library when I’m done with it. But the CyBook does render PDF, so I could at least use it for geek books, technical articles, Gutenberg downloads, etc.

Some libraries have started ebook lending. But the NY Public Library, whose print collection exceeds 50 million volumes, has exactly 945 Fiction titles available in ebook form, most available as only one or the other of Mobipocket or Adobe eBook. Given that Adobe manages to crap on the user experience of every product they put out, and that Adobe Reader still holds my grand prize for crashing Firefox & Safari, I don’t even want to go near Adobe’s ebook format, which they popularized in part by distributing DRM’d versions of Gutenberg etexts—evil.

The book industry seems to be doing its very best to imitate the visionary RIAA and MPAA. I imagine at some point the book industry’s proctologist will call them to tell them that he’s found their head. Until then I’ll keep lugging dead trees around.

Download the free trial version: 750 MB.

The downloaded disk image contained a non-folder icon called “Adobe CS3″.  So I did what Mac users always do—I tried dragging it to my Applications folder. The Finder popped up a dialog that eventually stabilized at “Preparing to copy 109,775 items.”

Well, that’s going to take awhile. I stopped the copy and poked around and finally realized the non-folder icon is actually a folder—nice job, Adobe—inside of which I  found a Setup program.  Aha, I thought, the Setup installer should be faster than actually trying to copy 109,775 separate files.

Wrong. The installer took 45 minutes on a 1.5 GHz PowerPC G4 Mac.

Then I had to download a 58 MB software update to get the Flash Lite 3 functionality recommended for Chumby developers. Not including download time, the updater took 1 hour and 45 minutes to apply a 58MB “patch”.

During this time, you’re not allowed to open any Web browsers, as the updater insists on updating various browser plug-ins. (But it doesn’t tell you when during the 1 hour and 45 minutes this occurs, so you have to forgo Web browsing the whole time.)

This “free trial” download experience does not encourage me to shell out the $995 Adobe wants for the product. (Hell, at my consulting rate, it’s already cost 2/3 of that to install the damn product.)

Maybe Adobe is used to Windows users accepting this level of user insult. Their PDF reader plugins for Web browsers are spectacularly unstable (Mac Preview is far superior), and even after CS3 was installed, it takes 30 seconds just to start up.  Their Flash plugin for Safari and Firefox on Mac seems to be the most frequent cause of those programs crashing (according to the stack trace, anyway, the crash occurs inside the Flash plugin).

So it’s finally happened: I’ve found other desktop software that makes Microsoft Office a dream by comparison. How sad from the company that basically invented PC imaging and multimedia. If I can find an open-source toolchain for Chumby development, I’ll use it even if I can get an Adobe academic license for free. This product deserves to LOSE.

Lesson learned: I’m always bringing my iPhone in the future! Although I did make a couple of calls on Mother’s Day ($1/minute) and send a couple of text messages (50 cents each), and I did find a number of Wifi hotspots (often free), I also:

• Took pictures, a couple of which I sent in real time to Tonia
• Used it as an alarm clock when sleeping in hotels that didn’t provide one
• On my laptop in Wifi zones, looked up stuff on the Web (walking maps, etc.) and sent it to the iPhone (via email) once I had the exact map(s) I wanted
• used it as an iPod
• downloaded podcasts of walking tours of Edinburgh, and transferred them to my iPhone

On this trip I had my laptop since it was for business. What would be great is if the downloading of generic MP3’s (not from ITMS) worked seamlessly on the iPhone without requiring syncing. I’m sure it can’t be far off.

Bottom line: always take your iPhone. Kick ass.