David Patterson - Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing, Beta Edition

Copyright 2012 Strawberry Canyon LLC. All rights reserved.

No part of this book or its related materials may be reproduced in any form without the written consent of the copyright holder.

Book version: 0.9.0

The cover background is a photo of the Aqueduct of Segovia, Spain. We chose it as an example of a beautiful, long-lasting design. The full aqueduct is about 20 miles (32 km) long and was built by the Romans in the 1st or 2nd century A.D. This photo is from the half-mile (0.8 km) long, 92 feet (28 m) high above ground segment built using unmortared, granite blocks. The Roman designers followed the architectural principles in the ten volumes series De Architectura (On Architecture), written in 15 B.C. by Marcus Vitruvius Pollio. It was untouched until the 1500s, when King Ferdinand and Queen Isabella performed the first reconstruction of these arches. The aqueduct was in use and delivering water until recently.

Both the print book and ebook were prepared with LaTeX, tex4ht , and Ruby scripts employing Nokogiri. Additional Ruby scripts automatically keep the Pastebin excerpts and screencast URIs up-to-date in the text. The necessary Makefiles, style files and most of the scripts are available under the BSD License at http://github.com/armandofox/latex2ebook .

Arthur Klepchukov designed the covers and graphics for all versions.

This book is an opinionated path through the bewildering array of methodologies, languages, tools, and artifact types that collectively make up software engineering. The goal is to instill good software habits in studentstestability, software architecture, modularity, and reusabilitywhile providing them the gratification of building a working deployed artifact that they themselves (and their peers) would use and find compelling.

This book is neither a step-by-step tutorial nor a reference book. Plenty of both are available online and in print; check saasbook.info for some suggestions. Instead, our goal is to bring a diverse set of topics together into a single narrative, help you understand the most important ideas by giving concrete examples, and teach you enough about each topic to get you started in the field. Throughout the book we recommend dozens of other excellent books that go into great depth about each topic; readers can decide for themselves which ones they will find most useful.

The particular choice we make is to teach agile development using a methodology similar to extreme programming (XP) in the context of building and deploying a software-as-a-service (SaaS) application implemented using Ruby on Rails. Each choice has a good reason.

We use the Software Engineering Body of Knowledge (SWEBOK), stewarded by the Institute of Electrical and Electronics Engineers, to introduce agile ideas and methods and apply them to the creation of SaaS, which we believe is important to the future of software. While agile might not be suitable for building safety-critical systems, its iteration-based, short-planning-cycle approach is a great fit for the reality of crowded undergraduate schedules and fast-paced courses. Busy students will by nature procrastinate and then pull several all-nighters to get a demo cobbled together and working by the project deadline; agile not only thwarts this tactic (since students are evaluated on progress being made each iteration) but in our experience actually leads to real progress using responsible discipline on a more regular basis.

Within each iteration, we are able to address the major issues of the software lifecycle in microcosmrequirements gathering with the customer, transforming requirements to user stories, driving the class-level architecture of the software using behavior-driven development, driving the implementation using test-driven development, and evaluating both unit/regression test coverage and acceptance/integration test results. That is, rather than first evaluating students on requirements gathering, then on good design, then on development and finally on test coverage and a working demo, all of these elements are evaluated on every iteration, encouraging the students to see the concepts and techniques as part of an integrated ongoing process rather than as isolated stages in a pipeline.

To motivate students, its helpful to use a platform that lets them create compelling apps. As of 2011, there were approximately 4.2 billion mobile phones deployed worldwide, or enough for 3 out of every 5 people on the planet; combined with the explosive growth of SaaS, we believe the future of software is client + cloud applications that are split between a tablet or smart phone and a cluster of servers to do heavy computation and persist data.

Therefore, both mobile applications for smart phones and tablets and Software as a Service (SaaS) for cloud computing are compelling targets for teaching students. As you can teach the principles with either target, given the time constraints of a single college course, we choose in favor of the platform with the most productive tools. Our experience is that it is no contest: the programming and testing frameworks for SaaS and cloud computing are dramatically more productive than those for mobile apps, and the client part of many SaaS apps can be adapted to mobile devices using the HTML/CSS/JavaScript skills learned in creating SaaS.

In addition, beyond the commercial promise of SaaS and the hireability of students who know how to create it, SaaS projects can be deployed inexpensively using public cloud computing, which means students course artifacts are on display for the whole world to see. The exposure and look what I made factor of public deployment are hard to match.

We want students to understand that in the real world, programmers are rewarded not for the number of lines of code written or for how quickly they can bash out a feature, but for functionality delivered with high assurance of stability and while keeping the codebase beautiful and maintainable for continued growth. To many students, especially hotshot coders who come into a software engineering course with nontrivial programming experience, the methodologies and techniques we use to do thisdesign patterns, refactoring, test-first development, behavior-driven designseem a strange and a dubious use of time.

We have found that students are more likely to gradually embrace these practices if given the best possible tools to support the practices. The Rails community has created by far the most seamless, elegant, and comprehensive tool set to support Agile and XP, and the idea of constantly refining and inventing tools that support testing as well as helping produce beautiful application code is a distinguishing characteristic of the Ruby developer ecosystem. While learning Ruby and Rails will be new to most students, juniors and seniors seem to learn it without difficulty, and far superior tools outweigh the learning costs.