I’ve been taking an edX course CS169.1x Software as a Service, which is a UC Berkeley course on building SaaS apps with Ruby on Rails.
One of the lecturers, Armando Fox, might be the most talented lecturer I’ve seen.
The authors openly embrace the concept of the 5 Whys and do a really wonderful job of not just explaining what to do, but why we do it. This fits in line with what I’ve read about effective learning: you need the big picture to tie together disparate concepts into a cohesive framework. Setting up the big picture allows you to snap the little bits into place with ease. And finally, when it comes time to apply that knowledge, the framework itself serves as a mnemonic.
The accompanying textbook, Engineering SaaS, which is written by the instructors of the class, is also rather good at providing a framework of “why”:
- Why do we build SaaS apps?
- Why is Rails a good choice to build SaaS apps?
- Why is Agile a good process for building SaaS apps?
- Why does Rails embrace MVC?
- Why do my instance variables disappear after each Rails controller action?
The course spends a decent chunk of its time explaining not only the Agile process, but the *opposite* of the Agile process, which is Plan-and-Document. It’s a smart choice to offer the alternate perspective because it ultimately strengthens understanding of Agile; again, it answers the question, “Why do we use Agile?”
On a personal note, as an old dinosaur who graduated from a CS program in 2004, it’s hilarious to see how much has changed. I remember taking a class dedicated to building software requirement specifications. We drew UML diagrams in Rational, came up with formal use cases, learned about Waterfall and Spiral, and oh yeah, there’s this new methodology called Agile that iterates super-fast but it’s sort of unclear if it’s really a formal methodology. I remember giggling to myself when we touched on Extreme Programming (XP): TOTALLY EXTREMEEE.