Wednesday, July 4, 2018

Computer Science vs. Software Engineering

Since we created the Software Engineering (SE) bachelors' degree five years ago, it has been interesting to watch the Computer Science (CS) and SE programs mature (and diverge).  When they are both in the same degree (as is true for most CS programs), SE is one of the typically required topics - often as the capstone - of the degree.  When you pull SE out into its own degree, two things happen: you have to define what CS is without an SE focus and you have to develop the full topic of SE.  We have wrestled with these questions with some consternation and, for a while, worried that we had essentially killed our CS degree.  Most of our students are going into industry, so why would they not be Software Engineers?  It turns out that there is value, even at the undergraduate level, in both programs.  I think we have come through this process with an understanding of the relationship between these programs that has allowed us to give each a unique, and valuable, identity.  And, I think the definitions we have arrived at are the normal progression of these programs.

The way we describe how CS and SE are related parallels other engineering disciplines:  CS is to SE like Chemistry is to Chemical Engineering or like Physics is to Mechanical Engineering.  CS is the science of computation and SE takes that science and builds things.  This definition gives each of our programs a unique perspective and allows our students to pick which program is best for them.

As the science, CS requires a broad understanding of the sub-disciplines of computing like artificial intelligence, databases, big data, graphics, etc.  It is the CS students who will expand the knowledge base, so they also need a good grounding in computability theory and run time analysis.  For us, the result is an interdisciplinary approach to computing because the problems that computer scientists attack are often related to other disciplines with examples like data mining in politics, AI in business planning, etc.  It turns out that the traditional CS curriculum meets the needs of this discipline pretty well except in the capstone project.  Freed from having a Software Engineering requirement, the research focus of CS manifests itself in our students' capstone project - an individual research project in which the student carries out an experiment following the scientific method just like all of the rest of the sciences. 

It is important to note that industry has a need for undergraduate computer science students.  They will be more prepared to develop efficient solutions to specific, topic-related, problems.  They will have practice with looking for state-of-the-art algorithms and adapting them to solve new problems.  Their knowledge of theory and run time analysis will help ensure that those solutions are efficient as well.

Software Engineers take the knowledge that Computer Scientists create and use it to build systems for industry.  In general, this means that Software Engineers are working on teams to produce large software systems. In order to do that, SE students clearly need some CS content. An SE curriculum must contain topics like programming, databases, and algorithms, but there are two broad topics that are unique to SE.  First, there is a design aspect to SE. In order for large systems to be robust, you have to plan carefully how the internal pieces of that system will work together to create the behavior you imagine.  It's like designing the Freedom Tower.  Not only do you have to think about how it will look and how people will use it, but you also have to think about how big a chase you create on the first floor to be able to run wires to get enough power to the hundredth floor.  That internal, invisible to the user, design is part of SE.  Second, if you are building a big system, you aren't doing it alone.  SE requires a team development process with strong communication deciding who is working on what, measuring our progress, and ensuring that we are building what the customer wants.  There are tools that SE teams use to coordinate multiple working on the software and managing the release of that software to customers. Clearly, that is a lot of material that is not in a traditional CS program.

When your goal is teaching SE, the resulting curriculum is VERY different from the traditional CS degree.  And I'll talk about that next time . . .