CMPT 395

Software Engineering

Winter 2014

I am currently in the 3rd edition of teaching Software Engineering.  My course is continually evolving (Why teach the same course twice?).  Since the first run of the course I have heeded advice and increased the content relative to

  • use of github for collaboration
  • exposure to open source development
  • guest speakers working in software development

Distributed version control systems (DVCS) and git in particular are becoming the standard for version control.  Almost every open source project uses git as their main source control mechanism or supports git.  While there are other very good DVCS systems like Mercurial, git is more popular.  Popularity aside, it is likely that wherever students end up, they will be using a DVCS tool in their day-to-day work.  Despite not being the easiest tool to use, I believe git provides the best foundation for any other tool my students may end up working with.

Open source development is an excellent way for my students to be exposed to an essential activity of development which is simply reading other people’s code.  All projects in my course involve modification of an open-source project.  This year my students are working with Ushahidi and IPython.  Aside from learning the art of reading others’ code and understanding the importance of style guidelines, using open source software reinforces the necessity of good version control habits to keep distributed teams organized.  Distributed software teams are the norm these days and preparing students to be efficient with collaboration tools is important.

Finally, guest speakers.  I’m not sure if students ever completely believe their professors/instructors.  One of the most effective ways I’ve discovered to reinforce the lessons I’m trying to convey is to have real developers talk to my students.  This term I was fortunate enough to have @vanaltj, @churchmf and @dijkstracula from Red Hat, Electronic Arts and Twitter respectively talk to my students about their life as new grads and eventually developers.Their presentations are excellent and cover a lot of the day to day activities of developers which include the tools they use, the importance of communicating and lessons they wish they learned in school.

Since I’ve been extolling the virtues of open source, I’m endeavoring to make my course materials open source as well.  I’ll post a link to them eventually.

Fall 2011

A disclaimer that I should make here is that I am not a software engineer.  I have taken courses in the subject area, but I have not done research or extensively studied what would be considered software engineering by most computer scientists.

I was given the opportunity to teach a new course in Software Engineering when I first arrived at GMU.  This task was both challenging and exciting.  Challenging in that I had to create a course in short order and exciting that I was given a lot of latitude in the kind of course that I could create.  In short, out went a lot of the standard SE material that I found boring as an undergrad.  What came into the course was a larger focus on tools, development, collaboration, communication and what I will generally refer to as “real world issues” like terrible or non-existent documentation.

A big piece of the course was working with a real world code base.   While a systems programmer by training, I decided to go with a somewhat conventional web-based application (common in SE courses).  Our class worked on Ushahidi, an open-source crisis-mapping application, that has a really cool history and was fun to work on.  Ushahidi has been used to crowdmap events such as elections all over the world, the Haiti earthquake in 2010, Snowmageddon in 2011, and numerous other events.  It’s a cool app with a lot of even cooler people behind it.

In a nutshell, the students were thrown at new languages, frameworks, tools, and deployment setups (web-based and mobile) that I think created an interesting and engaging course.  The students had a lot of freedom in choosing on what they wanted to work on which created a good share of headaches, but if there aren’t headaches, then it’s not software development.   Live and learn!

You can read in greater detail about the fun we had in this blog post for Ushahidi.