figure 4. survey results of software experience for former Berkeley students now in industry. (the waterfall software development process is characterized by much of the design being done in advance of coding, completing each phase before going on to the next one. the spiral model combines features of a prototyping model with the waterfall model and is intended for large projects.)

Waterfall Spiral

agile
other in-house

software Development style

68%

22% 5% 5% embedded Server Pc

 

software Platform

cloud (SaaS)

50%

enhance legacy S W

23%

Mobile

15% 4% 4% 4% objective c erlang

 

Language

JavaScript
ruby
Python
Java
c++
c PhP

22%

19%

14%

14%

10%

6%

6% 4% 3%

team size

1

2

3

4

5

6

7

8

> 8

21%

10%

14%

21%

10%

7% 3% 7%

6%

0%

20%

40%

60%

80%

100%

 

to simplify development of the classic three-tiered applications of cloud computing. In addition, because of cloud computing, deploying their projects in the same horizontally scalable environment used by professional developers is instant, free for small projects, and requires neither software installation nor joining a developer program. In particular, it frees the course from instructional computers, which are often antiquated, overloaded, or both.

One criticism of the choice of Ruby
is its inefficiency compared to lan-
guages like Java or C++. Since hard-
ware has improved approximately
1,000X in cost-performance since
Java was announced in 1995 and
1,000,000X since C++ was unveiled in
1979, 7 the efficiency of low-level code
matters in fewer places today than it
used to. We think using the improved
cost-performance to increase pro-
grammer productivity makes sense in
general, but especially so in the class-
room. Note that for cloud comput-
ing, horizontal scalability can trump
single-node performance; deploying
as SaaS on the cloud in this course lets
us teach (and test) what makes an app
scalable across many servers, which is
not covered elsewhere in our curricu-
lum. Once again, without using the
cloud to teach the class, we could not
offer students the chance to experi-
ment with scalability.

 

An example Course We use this approach to teach a software course, which currently has more than 100 juniors and seniors, at UC Berkeley. We also are offering the first part as a massive open online course (MOOC) to 50,000 online students, most of whom work in the IT industry and graduated from college five to 10 years ago. 3 (The MOOC tests the scalability of the tools and automatic grading of programming assignments.) Students follow steps shown in Figure 3, which turns the concepts and tools listed in the table into a logical process. Additional tools facilitate tying together the steps of this process; for example, Autotest monitors the source code tree in the background, automatically rerunning tests and user stories via RSpec/Cucumber in response to even minor code changes, giving immediate feedback if something breaks. Following the Agile philosophy, they deploy on Amazon Web Services (AWS) (via Heroku) multiple times during the course. The teaching staff evaluates iterations by interacting with the deployed app on AWS and by using Pivotal Tracker to check velocity and stories remaining to be implemented.

A typical faculty reaction to the request for students to deal with poorly documented legacy code is that it should not exist if students are taught good practices. However, despite decades of well-meaning instructors expounding on the importance of properly factored and highly documented code, our industry colleagues assure us the legacy code problem will continue to persist. Thus, on this point we quote Shimon Peres: “If a problem has no solution, it may not be a problem, but a fact— not to be solved, but to be coped with over time.” Hence, if we can find principles that teach how to cope with legacy code, they would be appropriate for the classroom since it is a long-lasting challenge.

To learn to deal with legacy apps, our students learn and enhance a large, popular, well-written (but poorly documented) open source app written in Rails. We use Typo, a blogging framework containing 30,000 lines of Ruby and 15,000 lines of JavaScript, which suggests that it has the functionality of a Java program of 100,000 to 150,000 lines of code. We choose a Rails app rather than a Java app to maintain the programmer productivity we need to fit within our time budget. Feathers2 argues that the first step is to write tests for legacy code to ensure understanding before modification, so enhancing