And so with the unusually good timing the universe sometimes provides, I stumbled on a great article in Communications of ACM called What Should We Teach New Software Developers? Why? by Bjarne Stroustrup. It discusses the disconnect between what industry wants from computer science graduates, and what universities aim to teach.
Industry wants computer science graduates to build software (at least initially in their careers). That software is often part of a long-lived code base and used for embedded or distributed systems with high reliability requirements. However, many graduates have essentially no education or training in software development outside their hobbyist activities. In particular, most see programming as a minimal effort to complete homework and rarely take a broader view that includes systematic testing, maintenance, documentation, and the use of their code by others. Also, many students fail to connect what they learn in one class to what they learn in another. Thus, we often see students with high grades in algorithms, data structures, and software engineering who nevertheless hack solutions in an operating systems class with total disregard for data structures, algorithms, and the structure of the software. The result is a poorly performing unmaintainable mess.There are some amazing software developers that come out of Carleton's computer science program. Some have even gone on to start their own successful companies. But there are also a lot who don't find meaningful internship experiences, and who have rarely (or never) written large software projects in a team.
Things look even more bleak for many grad students, for whom getting something that works just well enough to prove a particular result is more important than writing good, reusable code. I know I've definitely learned how to do exactly what is needed when it comes to course projects, and though I always wish I could do more, I know it is just not possible. Once courses are done, though, there is a great opportunity to keep your skills in check. I try to choose projects that require me to write code, and lots of it. I am also considering dabbling in the world of entrepreneurship to give myself an opportunity to write real-world software that needs to work well.
For those who aren't sure what they need to do for industry, or just can't find the right job or project to practice it, it would be nice to have a bit more balance in the degree programs themselves.
Industry would prefer to hire "developers" fully trained in the latest tools and techniques whereas academia's greatest ambition is to produce more and better professors. To make progress, these ideals must become better aligned. Graduates going to industry must have a good grasp of software development and industry must develop much better mechanisms for absorbing new ideas, tools, and techniques.I can't really speak for the industry side, but I am intrigued by the changes that faculty in Carleton's School of Computer Science are trying to make. Program streams like the upcoming option nicknamed the 'iPhone stream' are meant to provide the same core computer science as everyone else gets with a few extra classes geared towards a career in industry. Granted, these streams are focused on only a narrow portion of industry, but they are definitely a start.
This balance between academia and industry isn't going to be easy to achieve. I honestly don't know exactly how it should work. I like Stroustrup's suggestion of encouraging profs to code, but somehow that doesn't seem to be enough. It also always happens that when changes are proposed to our degree to help students be better prepared for industry, some students cry out that the program is being dumbed down, and that if you want to be so industry-ready you should go to college instead of university. Figuring out how to get the best of both worlds and make everyone happy won't be a fun job, but it's one worth talking about.
6 comments:
I'm not sure a whole stream is really appropriate. If they're looking to provide specialists in mobile computing platforms, they'd need enough relevent info to justify the course load. I could be wrong, but I think an introduction to mobile computing could be done in one course, leveraging prerequisites appropriately.
Begin with an intro to the platform of choice and how to get started with it. Give assignments which teach the theory around mobile computing while using the assignments as a means of cultivating practical working experience in doing what industry wants. Test on the assimilation of that theory. Throw in a final project allowing for individual creativity on something of somewhat larger scale/scope which rewards based on demonstration of the accumulation of assignment related skills -- bonus for finding and trying new things.
When it comes down to it, 3 months really isn't enough time to get into subject matter to the same scale of supportability/maintainability that industry expects. However, this is somewhat accounted for with marks attributed to good coding practices. About the closest things I've seen in CS towards this are 3004 and 4002. 3004 is/was just a rose-induced nightmare of poor documentation which forced you to figure things out by trial and error. 4002, when I had it, worked on the basis of a cumulative assignment. Each assignment was focused on some new thing, but depended in part on demonstration of previous assignments. The unspoken side effect was that if you didn't design well from the start, you were going to suffer for it later on.
This is somewhat cruel to the students when you consider the implications to something which isn't the focus of the course material. It's really hard to address the issue in a "fair" manner within the short timeframe that a course lasts.
Taking that in mind, it would probably be an idea (if it hasn't been done already) to take 3004 and toss rose out the window, teach the same basic theory using more elemental and industry-standard software (Aside: I've heard horror stories about companies that tried to adopt rose...), and leverage the same team-based environment with an aspect of the course dedicated to the handoff of code.
Musing a little on 3004... instead of consistent teams, have the students split into 3 or 4 role types. 1/3 is doing docs, 1/3 is doing back end, 1/3 is doing guis, and each team is really a "company". Every month, have students marked on the results of their work in their role type (employee review), and a mass layoff (might as well get used to the idea) forces everyone into the job market again, then they all get hired by different companies. So, the docs and source you wrote as part of team1 remains in ownership of team1's company, but now you just inherited the project of team2 and your new role changes between docs/gui/backend.
Maybe I'm drinking the wrong koolaid, but part of me thinks this could really work as a viable learning environment in ways the old 3004 failed.
Remember that the streams are really just the usual degree with an extra topical class each year. The electives rules have also been relaxed greatly so that everyone has more flexibility to complete their degree in a way they feel is most useful to them.
For the mobile stream, it's not just mobile really... the types of classes sound interesting too. More like a design studio than lectures. Check out the course info to see the topics, etc.
I agree that 3004 needs a lot of work, and the good news is that Christine L is working on it. :)
My school has a software engineering course, and it stresses documentation, version control and other such things, but there are three main problems:
1. The tools the students use range from bearable to terrible.
2. The projects are boring. In recent years they have been real world projects with real clients, but they're still not things students would get excited over.
3. The course tries to teach too many things at the same time: C++, GUI programming with Qt, UML, so on and so forth.
I'm putting together a proposal to revamp the software engineering part of our CS curriculum. Two of my main proposals will be:
1. Give students projects that they really want to do.
2. Use uniform tools and conventions as much as possible (ie, all submissions via version control, the same bugtracker and doc system).
I think that most schools do a not very good job at teaching software engineering and it's something that needs to be thought over well.
It's funny you say this - sounds JUST like our "3004" we were mentioning. That's the software engineering course in our program. I do think that the message of good programming should probably permeate all classes, and not just a small subset that are called software engineering.
I'm an adjunct professor at a small university in Austin, Texas. Next semester I'll be teaching software engineering and I'm sure that it will veer sharply away from the way it has been taught here in the past: the reason? Because I am a software engineer and have developed and lead very large projects throughout a long (20+ year) career.
Perhaps my viewpoint on teaching software engineering in university is self-serving, but I wonder how it is possible to effectively teach a subject with which most professors have no experience?
For example, there is the issue of complexity. In real world projects, complexity is like a threatening tsunami. It is impossible to convince students that the tenets of software engineering are in place to help them ride that rogue wave -- and not be ground under by it -- when their experience is limited to a gentle ocean swell. I recently was part of a $600,000,000 5 year project where the hardware, software, and vendor complexities were off the scale. One can't create this in the classroom and even a small approximation isn't possible.
However, what can be transmitted is the anecdotal experience of being in such a situation. That's why it would be good to get more practitioners involved in teaching software engineering so that it could be better rooted in reality.
Very good points Patricia - thanks for stopping by to comment!
Post a Comment
Comments are moderated - please be patient while I approve yours.
Note: Only a member of this blog may post a comment.