CMPS 276 - Software Engineering, Spring 2016

Instructor: Luca de Alfaro (luca@ucsc.edu)

When and where: TuTh 2-3:45, Earth & Marine B210

Resources

• Video on web2py development, and branch of web2py containint the code we developed in the second class.
• web2py
• Class document folder
• Server git repository
• Client git repository

About this class

In time, I have become convinced that the best way to learn how to build interesting multi-person software projects is to do one. And this is what we will do in this class. All students will participate in a single, large software project, writing code and documentation for their part, and reviewing code and documentation for the parts other students are writing.

The project topic will be unveiled at the first class. It will include elements of:

• Cloud development and web development for the cloud
• Modern APIs
• Internet of things
• Mobile development

The class will consist of a mix of:

• Lectures: I will give introductions to cloud development, cloud web hosting, IoT, APIs, mobile, and more, to get everybody started and working.
• Class discussion: On the project, and on the APIs and organization of the system.
• Code reviews.

To take this class, you have to be willing to write code, and try to write the code well -- not only it has to work, it has to be nice to look at. You have to know Python, or you have to pretend you know it well enough to fool your classmates by writing good Python code. Knowledge of Java is helpful for mobile development. I need at least a few people in the class who know linux (daemons, cron jobs, this kind of stuff).

You also have to be proactive and willing to experiment -- researching and figuring out by yourself how to make things work.

Rationale

I am teaching the class in this way for two reasons.

The first is that I have never held a deep belief that classical "Software Engineering", as in UML, requirement analysis, project management, project lifecycle, etc, actually made much sense, especially as taught or described in books. I suspected this already some years ago; it seemed too rigid a way to build software. A rigid methodology works for designing, say, houses, because most houses are in the end similar, but it seemed to me the wrong way to go about software, where the whole point is to do something quite different each time. Moreover, I have been writing software since I was about 15, and I have never used such methodologies. But I thought, perhaps they know better. Perhaps that's the way things work in the real world, and I just don't know the real world.

Since then, however, I have come to know the real world. I've worked for three years at Google, on projects ranging from reputation systems, ranking, Google Maps data, Google+, and more. I have founded CrowdGrader, and co-founded Camio. And I have seen how plenty of friends work on innovative software in Silicon Valley. My gut instinct was correct, and those stuffy methods are not used out there in the real world either (at least not where innovation matters most). So let's try to teach a class where you pick up how to collaborate with others (APIs, code reviews, design discussions) and where you can also pick up some elements of modern software development (cloud, APIs, mobile, web).

The second reason I am teaching the class this way is that, I am sure you disagree with me, but being a faculty is occasionally a hard job; many different things compete for my time, and the feeling of being "just threading water" is always present. Sometimes I feel the need for reminding myself why I am doing it. Why am I doing it? To have fun, of course! So half of the purpose of the class is to have fun building a really cool IoT-Cloud-Mobile platform on which we can ... play with a lot of cool ideas and things.

But, you have to be willing to participate, and be pro-active. You need to be wanting to do this and take the initiative on design and coding. If you want a class in which you are simply told what to do, this class may not be for you.