« July 06, 2004 | Main | July 08, 2004 »
July 07, 2004
Computer Science Isn't Programming
Jim Morris, who is a professor of computer science and dean of Carnegie Mellon University's West Coast campus has an article on Computer Science education in the Pittsburgh Post-Gazette. He says:
the vocational nature of computer science reduces its appeal to many students. Contrast what computer careers seem to offer with the promise of the traditional sciences that offer intellectual grandeur and the opportunity for a rewarding career that helps humanity. Since 1990, the number of undergraduate degrees awarded in the biological sciences has increased 70 percent. During the same period, the number of computer science degrees awarded each year has dropped by 10 percent. Today, we are producing about 25,000 computer science bachelor's degrees annually. The life sciences produce six times as many.
The current approaches to computer science education fail to teach the science of computing. As a result, they fail to inspire the very best and brightest young minds to enter the field.From Programming doesn't begin to define computer science
Referenced Wed Jul 07 2004 17:52:43 GMT-0400
I've got at least one corroborating data point: when the boom was happening, I had kids come to my office all the time, usually after their second year, when they get the living tar beat out of them with several large programming projects, and say something like "I don't like programming. Should I stay in CS?" I've had various feelings about that.
I usually told them that I knew lots of people who had degrees in CS but didn't program for a living. Some were system administrators, network engineers, lawyers, or doctors and lots were salespeople.
As Morris says, there are lots of interesting challenges in CS that go well beyond programming, but its difficult to appreciate them without at least an understanding of programming. I usually advised students that even if they didn't end up programming for a living, learning to program would give them a special perspective. Here are a few things I think they might get out of programming:
- People who program have a unique understanding of the relationship between static representations and dynamic processes (I have a theory that music composition students get a similar understanding).
- Participating in programming projects teaches you why its hard to get software right. You understand the non-linearity and brittleness of software.
- Programming as part of a CS degree should also teach students (although I'm afraid sometimes we fail) why learning to write small programs doesn't qualify you to engineer large software projects. We do a worse job at teaching how large software projects can be successful.
What other things do you think learning to program teaches a CS major even if the CS major isn't going to program for a living? I'd like your perspective.
06:11 PM | Recommend This | Print This
Gartner's Barking Up the Wrong Tree
Eric Nolin links to the Gartner reporton the iPOD and other firewire/USB storage devices. Eric's point is that this is one of the issues driving Web (or NET) 2.0. I agree. I think, however, that CIOs need more help than just saying "ban firewire/USB storage devices." This is the standard perimeter approach to protecting corporate data.
The problem with that approach is that its not feasible and getting less so all the time. I've got at least five devices in my laptop bag that could be used, potentially, to carry data out of a secure perimeter. Are you really going to tell people they can't bring cameras to work? What about cell phones? Watches? Heck, burning CDs is relatively easy with the standard corporate desktop. Some might think DRM is the answer, but its not. DRM is high overhead and requires careful planning of who has access to what. That's fine for high value data objects, but its not a general solution.
What businesses need is a way to audit user actions. I ought to be able to ask what the history is for any document and see not only the details about how this copy has been modified, but when and to who it has been emailed and any copies that were made, by who and to where. Processing audit logs scales linearly and allows you to focus attention on problem areas after the fact. Simple, workable, and solves most of the problem.