So, every year, the Computing Science Student Society produces a “Frosh Guide” for new Computing Science students. I remember typesetting our standard guide and adding batches of crazy rambling, one year.

As for “Advice for CS Students”, I polled Dan, Travis, and Dovic, and used their advice. The school did not appreciate Dovic’s advice.

The call has gone out once more, and so now I’m presenting my advice.

• Visit the IRC channel. (irc.freenode.net – #sfucsss) – it’s populated
  mostly by ex-CSSS who are industry professionals, and we know
  everything about everything.
• If a course says “Lecturer: Staff” or “Lecturer: TBA”, avoid it like
  you would avoid gonorrhea – unless you look forward to a whole
  semester of a clueless grad student reading PowerPoint slides off of
  an overhead projector.
• If a course says “Lecturer: Bart”, “Lecturer: Mori”, “Lecturer:
  Vaughan”, or “Lecturer: Baker”, take it. It doesn’t even matter what
  they’re teaching. Just take the course. I guarantee that it will be
  excellent.
• Occasionally crack open a textbook. Sometimes the concept that the
  lecturer has utterly failed to teach is in there, and explained in
  detail.
• Take notes in lecture and do the assignments, and nine times out of
  ten, your review-for-the-final will be a breeze. The tenth time out of
  ten, it’s because your professor dropped a big ol’ bridge-o-crazy on
  the class, and you’ll still do okay thanks to the magic of curved
  grading.
• All-nighters are a recipe for bad code.
• A lot of people come out of university with nothing to show for it on
  a resume except a hollow degree and a tiny amount of Java experience.
  This is bad. Do Co-ops, Project Courses, and Hard Courses. Do as many
  as you can. It’ll halve the time you spend in Junior Programming
  positions when you graduate.
• Try your very best not to do a co-op as a QA tester. The only
  experience that’ll give you is how to be a QA tester. It’s an unending
  loop of mediocre jobs.
• Bring a towel.
• Contribute to open-source projects.
• Have fun.
• You will never be surrounded by as many members of the opposite
  (/same) sex in your age, education, and interest group as you will
  over the next 4-8 years. As computing science students, this may
  occasionally mean that you need to branch out and try courses in
  Criminology, Journalism, or Biology. Join clubs. Meet people. You
  can hide in the protective shell of Computing Science culture for the
  entirety of your degree, and that’s just sad.
• Some students just come up to the mountain for classes, then go down
  immediately afterward. Soak up some SFU culture. Hang out somewhere.
• The student newspaper is terrible, until you consider that it’s
  written and edited almost entirely by amateur volunteers. They do an
  excellent job with limited experience and resources.

How exciting!

My prof for Software Engineering II is Danny Ridinger.

At the beginning of the semester, he professed an interest in iterative methods as opposed to the tired old dinosaur of Waterfall methodology, but it’s been several weeks, and it’s become painfully apparent that it is impossible to teach an old dog new tricks.

The course has been an impenetrable fog of scheduling charts, meaningless paperwork, and dated development techniques, straight from a man so ass-deep in “process” that I suspect he hasn’t seen a line of code in years. He subscribes to the sort of soul-sucking big-company software development techniques that treat people like replaceable cogs, the ones that require ten pounds of status reports per week, the ones where the entire software product needs to be planned, designed, and scheduled in advance, preferably with as little input as possible from those untrained plebeians who will be actually building the code.

Our first assignment was a “comparison” of RUP and Scrum, clearly one designed to paint Scrum in a bad light. RUP has a complete lifecycle model, while Scrum does not. Of course Scrum does not have a complete lifecycle model, it’s not Waterfall-style development. No matter how much the RUP tries to come off as an iterative method, when software is developed in discrete phases, each one with pre-planned schedules, and a set deadline, that right there, sir, is Waterfall. Other signs include that an iteration takes 6-8 months. That’s not an iteration, captain, that’s a full-fledged product. Budget, then schedule, then design, then code, then test. Waterfall. Bam.

The rest of the course has been a mixed bag of poorly-presented concepts. From techniques that are considered niche, even in the software world, to poorly laid out and rambling presentations about valuable real-life strategies. The day after a 3-hour presentation on Design Patterns, I spent 5 minutes explaining to a fellow student what a design pattern really is, and why he would want to use one. “OH! That sounds useful!” “They are. I have a book that you could borrow, if you’re interested…”

Many SFU students want the “Software Engineering” courses in CS revised to better address new development methodologies – iterative design processes – as well as peripheral, useful technologies like code repositories and debuggers.

I think the problem, though, isn’t the syllabus. The problem is that the people who are teaching the courses just don’t have the cutting-edge experience that we desire. They’re professors. Professors aren’t around to teach cutting-edge software development techniques. They’re around to learn incredibly difficult and obscure mathematical concepts and then apply them semi-usefully to the world of computers, getting published in journals and slowly advancing the state of computer science. Then, software R&D departments read the papers published by the professors, filter out the useless bits, and attempt to apply them usefully to new systems. There is no space in this loop for vocational training.

When I came to SFU, I was stoically in support of SFU being the sort of institution where students learned how to develop software. I disagreed with some of my friends — the ones who think that Computing Science and Software Development should be kept to separate institutions. “If you want to program, go to BCIT.” But I’m starting to see the light. It’s not that SFU shouldn’t teach software development. It’s that SFU can’t teach software development. SFU, by definition, lacks the sort of people who would teach software development well.

That is why we so dearly need the co-op program. It provides the technical experience that SFU lacks. I’ve learned more about software development from my co-ops — not the theoretical stuff, mind you, the real nitty-gritty coding stuff — than from all four years of my computing science degree put together.

SFU can teach theoretical computing science well — it fits the institution like a glove. SFU is about teaching students Lisp and Haskell, parser theory, grammars, how to write artificial intelligences that actually reason about things, what operating systems do and how they can be made to do these things better, fun times with logic, and enough math to choke a donkey. What SFU can’t do is teach students to code, or how to manage large software projects, or even how to contribute to large software projects. This is a thing that professors don’t do.

The only professor I’ve ever met who has been responsible for a large, long-term codebase of his own — at least one that he was willing to mention in class — has been Richard Vaughan, with his Player robot software.

So there is no place for Software Engineering I, Software Engineering II, or Information Systems Design at SFU. They teach fluff, nothing whatsoever. They fill space. They will always be mis-taught, for there is nobody to teach them properly. I feel that they should be removed entirely from the curriculum to make room for just a little bit more theory. Force students to take Compilers, or Graphics, or something painful and worthwhile, instead.

In my CMPT 475 (Software Engineering 2) class, the professor has repeatedly posited that “Something Is Always Better Than Nothing” — so far, in reference to the development of naming standards and the adoption of development methodologies.

Horseshit.

Now, ‘no development methodology’ may be a disorganized way to go about development, but a small team can make things work with little more than a source control system and a little bit of proximity.

It’s easy, however, to imagine both development methodologies and naming standards that would be actively detrimental to a project, both in terms of wasting time and in terms of actively confusing the system.

Naming

Starting with naming schemes— first and foremost, we can easily imagine a naming scheme that is actively detrimental to any project.

Start at n = 1. Every variable will be named _n, where ‘n’ is the order of introduction of the variable in the program.

This is, of course, a horrible, horrible naming scheme. A single line might end up looking like _12 = _14 + _29; . The only sensible way to make it work would be to maintain a table of data, mapping ‘n’ values to variable contents (maybe in code comments)? — nevertheless, there is no way that this naming scheme could be made elegant.

That’s— of course— a theoretical naming standard, and a pretty nonsensical one at that. Similar naming systems have popped up at theDailyWtf — the ‘a, b, c, aa, bb, cc’ variable naming standard seems to appear a lot, agonizingly enough. In general, though, we’ll consider this scheme totally nonsensical.

There are other schemes, however, that are very serious and standard, and still actively detrimental to a project. Here I refer to Hungarian Notation— and by Hungarian Notation, I mean “Systems Hungarian”, not the original “Apps Hungarian”. Apps Hungarian, when applied judiciously, can be a good thing for a project. Joel Spolsky wrote an entire article about it, here:

Apps Hungarian had very useful, meaningful prefixes like “ix” to mean an index into an array, “c” to mean a count, “d” to mean the difference between two numbers (for example “dx” meant “width”), and so forth.

Systems Hungarian had far less useful prefixes like “l” for long and “ul” for “unsigned long” and “dw” for double word, which is, actually, uh, an unsigned long. In Systems Hungarian, the only thing that the prefix told you was the actual data type of the variable.

This was a subtle but complete misunderstanding of Simonyi’s intention and practice, and it just goes to show you that if you write convoluted, dense academic prose nobody will understand it and your ideas will be misinterpreted and then the misinterpreted ideas will be ridiculed even when they weren’t your ideas. So in Systems Hungarian you got a lot of dwFoo meaning “double word foo,” and doggone it, the fact that a variable is a double word tells you darn near nothing useful at all. So it’s no wonder people rebelled against Systems Hungarian.

When it comes down to it, Systems Hungarian has some uses— but in many, many arens — for example, a small project in a dynamically typed language — it is utterly useless. It’s just a waste of time that introduces unnecessary code ugliness.

Methodology

Okay, development methodology can contribute a lot to the success of a project, I will admit. A carefully selected methodology can help a software project come in on time and on budget.

The trouble is, however, the postulate that any development methodology is better than no development methodology.

Once again— two guys with a subversion repository — with no development methodology at all — will likely outperform two guys using a heavyweight system like the RUP. The amount of overhead and paperwork involved in a heavyweight methodology almost necessitate a full—time project manager to learn it and deal with it all. Sure, for larger, longer projects where you’re managing hordes of replaceable cogs, you’re going to need some serious Process — but if you’re building a little blog package with one other guy, well, too much Process just wastes your time and holds you back.

Conclusion

Seriously, the ‘anything is better than nothing’ mindset is almost always a very bad idea in the tech world. Most of the time, ’something is better than nothing’ — I’d rather have the Vault or even Microsoft SourceSafe (shudder) than no source control at all — but we must not confuse minimally functional solutions with actively detrimental solutions.

I’m not going to lie, I’m a bit disappointed by the CS department’s 400-level-summer-offering this semester.

How many 400-level-courses is the CS department OFFERING, Curtis?

Well, mysterious question-asking stranger- 4, one of which is in Harbour Centre, one of which I’ve already taken, one of which is in The Wrong Stream, and one of which is Complicated and Mathy.

I only need 2 400-level courses (and MACM 316) to graduate- I was hoping I’d be able to do it over the summer. I guess not.

So, my plan has always been something along the lines of

• Just barely pass undergraduate university courses
• Work in “the field” for several years.
• Eventually grow bored with professional programming.
• Return to academia, get more degree. Become a cranky old professor with an incredibly obscure specialty.

I always figured that this plan was technically sound- but now that I look closer, I wonder if schools looking for grad students will accept field experience in lieu of an actual decent GPA or research experience. Any insight, interwebs?

In a class of 57, my backgammon AI placed 7th out of 34 entries.