On Software Engineering

The topic for class this week was on the Principles of Software Engineering.

When we talk about software engineering, what comes to mind for most people is programming. Some people think that software engineering is merely a fancy name for programming.

Clearly, programming is the foundation of software engineering. Without programming and competent programmers, it is impossible to build complex software systems. However, software engineering is much more than programming and I shared with the class the story about group of elite programmers in CS3216 who blew up on their assignment last year.

Truthfully, Software Engineering = Programming + Process + People.

CS3216 is about making a difference. How does one make a difference? It doesn't take a rocket scientist to figure that there are two key steps: (i) come up with an idea; and (ii) execute.

With the Final Project Proposals completed, all the groups have already come up with their killer idea to take over the world. Which group will succeed? Well, it depends on whether these groups successfully execute their killer idea.

It is in this light that we had this last class about Principles of Software Engineering. One doesn't become a software engineer by attending this one class. However, I do hope that by highlighting the key considerations that the groups should keep in mind when designing their application, they will avoid potential pitfalls and bugs.

Also, the final part of the class where I got three students to share their experiences on how they managed various projects has a clear purpose.

Wei Man managed a large team of 80 at LucasFilm in developing a big commercial game using Scrum. Justin managed a smaller team of 6 people at GAMBIT in developing a smaller game over three months. Zi Han did a scrumish-agile-bastardized thing in leading a small group of 5 inexperienced programmers to develop a full-fledged commercial system in 3 months. What did I hope the students would learn from their sharing?

Tools and Processes are Available. First, there are tools and processes available to help manage a software engineering project. From Scrum to Trac to Microsoft Project. There are many tools and frankly I don't know all of them and neither do I wish to discuss them in class. Instead, I would encourage students to explore and perhaps to ask Wei Man, Justin and Zi Han.

Tools are Dead, People are Alive. Tools are no good without the people. And regardless of how effective a tool is, it is useless unless we have people who are trained and committed to use them. Also, not every tool is suitable for every situation and for everyone. People better go and pick the tools that are useful for their projects.

It's all about People. At the end of the day, software engineering is about a group of people coming together to build a large software system. The biggest problem is the people. Much of execution therefore lies in getting the right people for the job and then motivating them to do the right thing to get the job done. This is an art form that cannot be taught in school in my opinion. Students will have to pick this up from doing stuff.

The coming week is going to be tough 'cos I expect the first prototypes for the Final Projects to be ready by next Friday. That said, I have met with all the groups and emphasized like two million times to keep their prototype small.

Don't have to save the world. Just pick a small and relatively common problem, i.e. used/needed by 80% of the people and nail it well. I hope that the discussions this week and the sharing would be helpful to the various project groups.

Next week, we will cover another topic related to execution - in case some of the projects turn out to be runaway successes with millions of users: how do we design systems that will scale up to millions of eyeballs?