DevOping the MS computer science curriculum
What I am going to say here applies mostly to training software engineers. Training theoretical computer scientists is a different matter, and my guess is that that is already being done pretty well.
The problem I perceive is that software engineers are being trained at universities by using methods more appropriate to training theoretical computer scientists: what's students get when they sign-up for an MS in computer science is the first portion of the curriculum used to train theoretical computer scientists for doing a PhD. Now, that knowledge is not useless to a working software engineer: all of the top working engineers have some understanding of theoretical computer science. Certainly, a good engineer should know what is being said when someone points out, "But your algorithm will run in exponential time," and have knowledge of how to determine the asymptomatic complexity of an algorithm they are considering.
But this is a minor part of most working engineers jobs. When presenting a proof for the runtime complexity of an algorithm in one of my lectures, I pointed out to my students, 99% of whom intend to be working engineers, and not theoreticians, that we engineers certainly should not be frightened of these proofs. But, I noted, they really won't play much of a role in your future jobs: in 20 years of professional software development, I told them, I had never once had my manager come to my office and demand a proof of the runtime complexity of the code I was developing.
To properly train of working engineer, one has to have them develop software, especially real software, that will actually be used by real users, rather than toy software developed simply to pass a class.
This implies that to properly train software engineers, MS programs must be able to offer them real projects to work on. But what kind of software for real-world use can an MS program possibly be involved in developing?
Answer: the program's own courseware! Of course.
So the new paradigm is: make your courseware open source. Make it buildable. Make it testable. Allow continuous integration and setup automated testing. Create monitoring systems that provide rapid feedback as to the success of the courseware. Put your courseware in an open source repository. But most of all:
Realize that, if you are training MS Computer Science students, you are a software company. Treat the entire enterprise as a single software project, developing agile courseware. Maximize the opportunites for sharing code and knowledge amongst all courses, and make the MS students an integral part of this process.
The problem I perceive is that software engineers are being trained at universities by using methods more appropriate to training theoretical computer scientists: what's students get when they sign-up for an MS in computer science is the first portion of the curriculum used to train theoretical computer scientists for doing a PhD. Now, that knowledge is not useless to a working software engineer: all of the top working engineers have some understanding of theoretical computer science. Certainly, a good engineer should know what is being said when someone points out, "But your algorithm will run in exponential time," and have knowledge of how to determine the asymptomatic complexity of an algorithm they are considering.
But this is a minor part of most working engineers jobs. When presenting a proof for the runtime complexity of an algorithm in one of my lectures, I pointed out to my students, 99% of whom intend to be working engineers, and not theoreticians, that we engineers certainly should not be frightened of these proofs. But, I noted, they really won't play much of a role in your future jobs: in 20 years of professional software development, I told them, I had never once had my manager come to my office and demand a proof of the runtime complexity of the code I was developing.
To properly train of working engineer, one has to have them develop software, especially real software, that will actually be used by real users, rather than toy software developed simply to pass a class.
This implies that to properly train software engineers, MS programs must be able to offer them real projects to work on. But what kind of software for real-world use can an MS program possibly be involved in developing?
Answer: the program's own courseware! Of course.
So the new paradigm is: make your courseware open source. Make it buildable. Make it testable. Allow continuous integration and setup automated testing. Create monitoring systems that provide rapid feedback as to the success of the courseware. Put your courseware in an open source repository. But most of all:
Realize that, if you are training MS Computer Science students, you are a software company. Treat the entire enterprise as a single software project, developing agile courseware. Maximize the opportunites for sharing code and knowledge amongst all courses, and make the MS students an integral part of this process.
Comments
Post a Comment