Aspects of CS not taught at Uni

Eric Sink has just started a series of articles on Source Control: an introduction for SCM novices. In his introduction, he writes:

"My goal for this series of articles is to help people learn how to do source control.  I work for SourceGear, a developer tools ISV.  We sell an SCM tool called Vault.  Through the experience of selling and supporting this product, I have learned something rather surprising: Nobody is teaching people how to do source control.

"Our universities don't teach people how to do source control, or at least mine didn't.  We graduate with Computer Science degrees.  We know more than we'll ever need to know about discrete math, artificial intelligence and the design of virtual memory systems.  But many of us enter the workforce with no knowledge of how to use any of the basic tools of software development, including bug-tracking, unit testing, code coverage, source control, or even IDEs."

Coincidentally, I also saw Jim Gries' Debugging Glossary post when reading through the blogs.msdn.com feed (actually I read this through the browser rather than either of my aggregators), in which he says:

"[D]uring a recent UI meeting here at work, one of our PM's (Habib Heydarian) mentioned that while at Tech Ed, he was shocked at just how many developers don't have an understanding of the terms used while debugging, let alone how to use a debugger effectively."

In my final year at Aston, the CS department were looking for ways to improve the performance of the Combined Honours students taking the Introduction to Systematic Programming course (no longer on the website; since I wrote my last post on the subject, the site has been updated, and now the initial programming course [PDF] is taught in Java). Formerly, lab sessions were run by either the lecturers or by post-graduate students, many of whom were unfamiliar in Ada, the language taught. That year, the department decided to ask final-year undergraduate students who had scored highly in ISP to assist with lab sessions. I was one of those people. The hours weren't onerous (two or three one-hour sessions per week) and the pay reasonable at £8 per hour, which helped a little.

By this point I'd bought and read, on Ian's recommendation, Steve Maguire's classic Writing Solid Code, in which he recommends single-stepping through every new piece of code you write using an online interactive debugger. Doing this as a matter of course opened my eyes - desk-checking a program is all very well, but you run into the problem where you think you know what the code does. You miss the bugs because you're not looking for them. There's no substitute for actually running the program and seeing what it does, and if you single-step, you find out exactly what code is hit and what your variable values were.

When we were asked for suggestions for the course, I suggested including a session on using the debugger. We were limited of course by the available tool suite: using GNAT as the compiler and hence GDB as the debugger (actually the gdbtk GUI front-end). However, any debugger is still better than trying to debug through print statements. The edit/compile/run cycle to add a new statement to print some variable you missed last time distracts from the sessions.

This suggestion was radical because many lecturers were of the opinion that online interactive debuggers are useless; after all, you've formally proved your specification, used a CASE tool to generate your code and desk-checked any hand-written code - how can there possibly be bugs after that?

Over here in the real world we know that formal proof works only for really small systems and takes a really long time and therefore costs a lot. We also know that a CASE tool can only really generate programs that the CASE tool's designer intended it to build - novelty is heavily restricted with these tools.

CS course designers: do your students a favour by learning how to use a debugger, then teach your students. If you need a resource, or a course textbook, try John Robbins' Debugging Applications for Microsoft .NET and Microsoft Windows. Yes, it's Windows-centric. Yes, it's far more than just an introduction to debugging - it even has some material on optimising your working set toward the end. But the first three chapters (part 1 - The Gestalt Of Debugging) are a must-read for all developers, on any platform, with any language, using any debugger.