Should universities be teaching SCM/methodology skills?

Question

Most CS programs these days do not teach skills such as:

• source control
• configuration management
• integration (and continuous integration)
• code readability (AKA how to comment correctly)
• programming methodologies
• bug tracking

These topics are considered easy enough to be taught on-the-job (OTJ), even though mastering them can be very complex.

Should these skills be taught in universities? Can a real-world programmer really do without these? Is it sufficient to learn them OTJ, as part of a first-year programming experience?

Answer 1

At my university course they do a required module in the second year for team programming, where using source control is required (and taught), however as far as I know none of the others are taught (although you may pick some of them up in team programming modules).

As for if they should be taught, yes, I think there should at least be an optional module for these things.

Answer 2

I think scm and issue tracking are mostly communication skills.

It would be important to have such a course in computer science universities, but from what I've seen communication skills are not highly rated in cs universities :)

Answer 3

Yes, why waste a company's time and money learning what I consider to be basic skills to know in this field?

At the very least, classes should enforce their use or encourage learning of these technologies outside of the classroom.

As for learning this stuff in the first year, I think source control should be taught in the first year of programming. This gets people used to using it right off the bat.

Answer 4

Having one course on this would be beneficial, or even lumping it in a C++ course. These days many company's use SCM's and typically people don't understand what they are doing with them until they've used it for a few weeks. Some advanced concepts should be tought on SCM's, such as branching and branching strategies. In addition, continuous integration is a big thing now so that could be thrown into the mix.

Answer 5

I think they should be taught in schools. Some people that I have worked with do not understand the concepts and learn by getting kicked in the ass on the job. To me, it looks like that hurts.

When you don't know those thing that you mentioned, you don't just waste you own time learning the basics of software development, you waste your whole team's time and the company's money.

P.S.: I think that you missed another big point that is lacking in CS programs: the ability to work in a team environment.

Answer 6

It's really difficult within a single semester to teach about software engineering tools and put together a project in which you make use of the tools, which is really the only way to become reasonably acquainted with them. In programs with a two-semester project or capstone course, I'd like to see them take advantage of the extra time to add things like SCM to the expectations for the course. For semester-long courses, you really need to have someone who is already familiar with SCM to be able to configure and instruct others on how to use it for it to be effective. I have done this in some of my courses, but I'd been in industry for several years before going back for my MS.

Certainly professors should be encouraging their graduate students to make use of SCM with their research code -- as well as having good backups, etc. Developing code for your thesis without an SCM is as foolish as developing code for a living without it.

Answer 7

Yes, they should. CS education is very unusual. In other science disciplines like Chemistry, Mathematics, Physics, etc. students will spend a fair amount of time in lab work using the same (or similar) equipment and techniques as those used in the field. Yet almost all Colleges and Universities are content to leave their Graduates ignorant of the tools and techniques that have been critical in the industry for decades. It is silly, and actively harmful, to churn out paper CS graduates who have no knowledge of SCM, bug tracking, refactoring, unit testing, integration, and development methodologies.

Answer 8

I did learn most of that stuff at University.

Our second year contained a module that covering the theoretical side (methodologies etc), and a module with a group programming project that introduced the practical side.

While we were never graded on our use of version control (SVN exam anyone?), it was introduced in lectures, and you'd have been a fool not to use it on the group project.

Answer 9

In my opinion, it should be taught, but not necessarily as a specific class. Instead, all course-related software development should be performed under realistic conditions, which means source control, comments and error-handling. Teaching it only as a single-semester afterthought, however, is pretty much worthless.

Of course, this goes back to the question of whether the school is trying to teach software engineering, or just computer science.

Answer 10

One big issue with the topics you mention is they are related with software lifecycle: it is not before the first release and the subsequent maintenance phase that you realize how much those skills are actually vital.

Any student can see the benefice of those topics (like for instance, basic revision control or correct comments) on a punctual basis, during the course of the implementation of a long cs project... but once that project is delivered (and evaluated), that's usually it. The project is "done and done". Over. No need to maintain or refactor it.
That means: the lifecycle is quite short, limited in time and simple.

It is not before you are confronted to a complex release workflow (often within a medium to large team) that you really need to setup a full software development infrastructure to support the various development efforts.

Answer 11

No - well not directly and exactly these topics, but universities should make sure people get their hands really dirty, by hacking in as much code as possible, make sure they stick to solving problems even at late hours when the well-behaved folks are already deep asleep, just to fix that problem, hands on...

No one learns coding (software engineering?) by just listening and taking notes in class. (All) you need is practice, practice, practice... and universities seem to have a hard time checking on this...

Answer 12

Universities should be teaching how to read, write, learn and think logically. They should be teaching the practices that lead to knowledge generation, as opposed to simply lists of "facts". For an educated, intelligent person, learning how to use source control and understanding the basic concepts behind it are trivial exercises.

Thus spaketh MusiGenesis.

Answer 13

Disclaimer: I am a university professor, and I am leading an effort to revise our undergraduate curriculum. What follows are my opinions.

• Universities should teach distributed source control starting with the first programming course. It is a fine way to distribute code to students; they can get bug fixes easily. In later courses they can use it to help support pair programming. We should treat it as easy, make it a habit, and not make a big fuss about it.

• Universities should not teach configuration management. There is no consensus on what tools should be used or how they should be used. The dominant tools are either proprietary (Visual Studio) or far too complex to teach to beginning students (GNU Make). I have recently stopped using make in my classes, and life is easier for everyone. Students compile all their source code, every time, using a shell script.

  The difficulty with configuration management is that the complexity of current tools obscures the underlying ideas of lasting value. This is true of GNU Make and even more true of autotools.

• It is nearly impossible to teach integration at university, let alone continuous integration, because everything has to be broken up into course-sized units of 10 to 14 weeks. Even worse, within a single course, programming work is typically broken into small pieces, each of which takes at most a few weeks to complete. These constraints militate strongly against learning how to integrate systems.

• Code readability should be taught from the first programming course and should continue to play a role through graduation. In both my introductory courses and my upper-division undergraduate courses, about half students' homework grade is for readability.

• Programming methodology is another essential topic that should be taught at university, but perhaps not in the way you think. If university graduates really understand data abstraction, criteria for decomposing systems into modules, data-driven design, and maybe stepwise refinement, they are doing well. Yes, all this was understood by professionals as long ago as 1980, but these ideas are still fundamental, and I am confident of their lasting value.

  Regarding some of the other stuff out there, UML does not have a foundation of lasting value, design patterns are a culture, not a methodology, and (this last backed up by experience) the design of class hierarchies and the use of inheritance is too advanced a topic for most undergraduate students.

• I don't see that bug tracking has enough substance to be taught at university, and I don't see any obvious situations where students would find it helpful to use bug-tracking tools. There's a big contrast with source control, where the opportunities and benefits are obvious.

Answer 14

At my university, the major theme of software engineering courses was "Controlling Complexity." As software engineers we have the benefit that the systems we engineer are not effected by things like mechanical wear or physical limits(up to a point), as such it's very easy for a software system to grow so complex it's incredibly difficult to imagine.

Controlling complexity is paramount to building good and effective software systems. I feel that most of the topics in your question are all useful ways of controlling complexity, and as such should be taught in universities.

Answer 15

I think CS is equivalent to Maths course in Computer world. Software Engineering is equivalent to Electronic (Mechanical) Engineering (to build something based on CS).

I would say, those technique you mentioned is optional for CS student, but for Soft Eng student, it is a must. Those technique are meant for communication among a group of people. It's a discipline.

I can't imagine how Soft Eng student involving in large development without using those tools / practices.

Software engineers are soldiers. SE students needs to be taught in school about the how to work efficiently before going into battlefield :D

Answer 16

Colleges, at least as they are defined with Canadian and US post-secondary education terminology, should have courses on this stuff and it may be useful for the school to have a program that is continually under revision so that students can go from requirements to maintenance and deal with different issues around the idea of a mock software development shop. To my mind, this is close enough to the real world that colleges should be able to have courses around different parts of this so that students can learn various methodologies in an academic setting but not be something that one could hand to the students about to take the course to get the homework done in record time as the work would change each semester.

Unit testing is something left off the list that I think I'd add but these all fall into courses around software development which isn't necessarily a requirement in CS programs. I do remember learning about Version Control Systems and some ideas around testing like black box and white box testing in my second year Computer Science courses.

Answer 17

Yes, absolutely. Universities should teach, in addition to writing code, itself, the basics of Subversion, Trac, CMake, Ant, Maven2, Doxygen, and other technologies which facilitate the development process.

Answer 18

I imagine you guys are talking about universities in the USA or probably in countries of an anglosaxon tradition. In my experience, "computer science" is a misnomer there, and what Norman Ramsey wisely describes at the top should (IMHO) be better termed "information technology" or even "software engineering".

If we are talking about software engineering, then I fully agree with Norman. If we stick to true computer science (data structures, algorithmics, compilers) then I think we need to keep discussing. :-)