Computer Science Education Is A Partnership
Some time ago, Jeff Atwood posed the question: How Should We Teach Computer Science? In the article, he laments the fact that formal education doesn't teach students about deployment issues or source control:
And yet, as Greg notes, existing software engineering textbooks give this crucial topic only cursory treatment. Along the same lines, a few weeks ago, a younger coworker noted to me in passing that he never learned anything about source control in any of his computer science classes. How could that be? Source control is the very bedrock of software engineering.
While I agree that any good software engineer needs to know about source control and deployment, I think it's unreasonable to expect that formal education is going to teach students everything they need to know. What universities are good at or at least should be good at, is teaching people to learn. The actual content they learn isn't anywhere near as important as developing the skills to go out and learn things for yourself. There's simply no way that students can come out of university knowing everything they're ever going to need to know in their jobs, so they need to learn to learn. That's why Jeff's suggestion that computer science should be taught in conditions as close to reality as possible is the wrong way to look at it:
Today's computer science students should develop software under conditions as close as possible to the real world, or the best available approximation thereof. Every line of code should be written under source control at all times. This is not negotiable. When it's time to deploy the code, try deploying to a commercial shared web host, and discovering everything that entails. If it's an executable, create a standalone installer package that users have to download, install, and then have some mechanism to file bug reports when they inevitably can't get it to work. Students should personally follow up on each bug filed for the software they've written.
This kind of experience is a critical part of student's education, but it's not the only important part. Getting a solid grounding in all the abstract theory, the history of computers and a range of different types of programming languages - even if they're almost never used in the real world. If education is just trying to simulate the real world, we'd be better off just canceling all the CS courses and letting people learn on the job. What's missing in the IT industry is the understanding that providing education is a partnership between educational institutions and the industry. Neither can provide the education new software engineers need alone. That's why most software engineer jobs require or at least prefer a CS degree.
Universities should focus on providing the theoretical knowledge that underpins computer science and teaching students how to learn for themselves. Industry should provide internships and partner with universities to give students experience working in real teams on real projects. A simulated development environment will never be as successful as a real one and on the job training will never give students enough of the technical underpinnings to master their craft.
That's why Ephox got involved with Griffith Uni last year to bring in a team in their final year project where they developed real software for us in a real environment - complete with source control and deployment. That's why we prefer hiring people who are quick learners and passionate about technology even if they don't have all the knowledge or experience yet. That's why we go out to university events and make contact with universities (and schools) to help bring more of the real world into their education and to help make them the best possible software engineers.
Computer science education is a partnership - what have you done lately to hold up your part in that partnership?
January 30th, 2008 at 2:00 pm
I was just recently thinking of some of the vast differences in a university education vs what is required in the real world. One of the things I found very interesting is that for the majority of early university projects, we were given some base interfaces/classes and expected to write the rest of the code to accomplish some functionality. Universities are always on the lookout for plagiarism, so the best application was one written entirely by yourself.
After a few years in the industry, I realize first hand that if everyone write their own in house code for every bit of functionality, you end up with a maintainability nightmare. There are a wealth of 3rd party libraries out there that provide much more robust solutions than can be rolled in house. Some of the later projects in university definitely allowed the use of third party libraries, but I don’t remember this ever being explicitly encouraged, more that the restriction was silently removed on larger projects.
Sure, part of a university degree is to teach people how to program well, but the ideal being they can then utilize this skill when it is required. However there is very little focus on having development the second solution, after research into existing solutions yields no results.
I think this would be a very valuable area to explore in a university curriculum. As a part of this, students would also get a feel for understanding software licenses. I wonder how many graduates understand the difference between the GPL and LGPL? As previously stated, a university degree should not aim to teach everything, but rather to teach us how to learn. Getting students to understand the legalese in a couple of software licenses would provide a solid base upon which to read and understand other licenses they are no doubt going to come across.
Just my 2 cents.
January 30th, 2008 at 3:55 pm
Uni and the workplace are such different places. I was lucky enough to work in IT during my degree, so I got the benefits of both worlds and appreciated the difference.
If you work on a large team project at uni, you pretty much have to learn subversion or cvs. But, this is pretty easy - you just pick it up as you go. You don’t need a class for it.
I don’t think Software licensing is important to learn at uni. Yes, it’s an issue, but there are far too many other important things to cram into a 3-4 year degree.
It’s difficult for unis to balance the theoretical and practical. They have to deal with theoretical, so that students get the general skills they can apply to any technology. However, they have to also teach practical skills, so the students don’t have their heads in the clouds, and don’t have any marketable real-world skills. Its a tricky balance to strike… but, in the workplace is mainly practical, so uni should focus on theoretical.
Certainly, what I got from uni was a deep understanding of the theoretical side, and I wouldn’t trade it for the world. It has helped me put every practical skill I know in perspective.
However, I naturally think very analytically and abstractly - as does AJ, I’m sure. So, this type of person will thrive in this environment, and be able to apply it to more tangible skills.
Lots of people aren’t like that - they need to learn the practical skills first, then abstract that to the general cases. On the one hand, these sorts of people should be catered for. On the other hand, IMHO, these types of people should not become engineers. :)
But, seriously, an engineer’s job is to take abstract principles and apply them to a practical skill to solve a problem. The practical skill changes, but the abstract problem solving techniques do not. Especially for software engineering - I’ve always thought that software engineering is one of the most pure abstract problem-solving pursuits there is.
There were a few things I would have liked to see added to my course:
- Learning TDD or at least automated testing, rather than quality principles. Still need quality principles hardcore… but I left uni with no practical testing skills. I learnt more about testing by doing the interview programming exercise for Ephox, than I did at uni.
- Learning how to maintain/refactor bad software. So much of uni is greenfield - start from scratch, design this application, you’ll never have to maintain it. As well as this, I’d like to see: you have legacy system x with heaps of faults. Inject a new feature into it. Refactor it. Extract and re-write subsystem y without breaking the tests.
- Web development. I know this is a very practical skill… but its very important these days. We had 2 year-long uni projects - both of mine were web apps, but we’d learnt very little web stuff. I picked up some bad habits, and learnt lots of things the hard way. One subject would be heaps to avoid these pitfalls.