The Joel on Software Discussion Group

Because the student editions of many ide's don't support version control. You see, you need the "enterprise" edition for that...

"Learning version control" is at most a one day non-event that any hish-schooler should be able to figure out.  I don't care if a graduate doesn;t know it - it will take a short while to bring them up to speed - if that is the only thing missing from a candidate it is a no-brainer.

Now, if it was a 5 year veteran of software development in the real world, then I think we'd have a problem.

College is not about learning practical things you can pick up in a day on the job.

Students don't need to learn version control because:

1. They don't work on projects large enough to need it
2. It takes between 1 and 3 minutes to learn how to use a properly designed version control system. This will happen during your first day on the job.
3. Every company has their own version control and those 3 minutes of details are different for every product

When people bemoan that students are not being correctly trained in version control technology, it just identifies the person speaking as either an idiot who is clueless about development, or someone trying to pull a fast one.

Half the companies I've worked for as a developer lack source code control. Why complain about just the students lacking SCC?

TimJ sums up my thoughts exactly.

Students don't learn version control because most university professors have no experience writing software for a real business.

@FSK - that may be true - but that is hardly the reason.  It is a trivial concept that has no meaningful bearing in the academic world.  The CS coursework and syllabus really doesn't address it, and I don't think it is very important for a CS degree.

I think it would be a wonderful seminar - like a one hour lunch, or a single day/2 hour "lab" or survey class/demo.

It's freakin' source control.  It's not rocket science.  The way some people carry on about this you would think that the universities are teaching creationism or something.   

It's a non-issue, folks.  If a candidate can't figure out version control on his/her first day on the job they don't deserve to be working in this field.

I learned about version control, using RCS <shudder> in my Software Engineering class, where we actually had a multiple person project to work on.  The class was otherwise a huge waste.

I didn't actually use any version control until I was about 5 years into my first job.

Everybody thinks version control is a walk in the park, right up until the minute they have three branches and forget to retrospectively fix a bug in one of them, or the automatic merge does something "helpful" that introduces a bug without anybody even noticing (of which SourceSafe is particularly good at if you don't keep your wits about you).

@Ritchie - that is something different.  We're not expecting them to know how to administer  source control or set policies - just that they can use it.

And I would submit that if you routinely have problems like what you are describing then your process is broken or could use some work. 

Do you really think a version control "class" would resolve what you are pointing out?

As an aside - I think a version control system would be a fantastic project for CS students.  It touches many aspects of the CS curriculum

- networking
- concurrency
- database/file system
- transaction processing

I have no problem with making it a project, but it is silly to think that colleges are somehow dropping the ball because some students don't know what it is.  That is utter nonsense.

And that's true, and is where version control turns into a nightmare that is more trouble than its worth. Obviously there's no college project that is going to get large enough in one semester to have multiple branches and fixes going on simultaneously, or the requisite hundreds of developers for it to be an issue. You only run into those problems working on good sized projects.

In decades of using version control, not once has it saved my butt. I mainly use it for documenting changes in each version, and for cloning the source tree to a new machine.

Once in the workplace, a new guy somehow managed to erase everyone's source trees by getting onto the source server and deleting everything there. He was trying to undo a mistake he had checked in and didn't want a record of it and typed rm -rf * the wrong way. No problem, all was backed up on tape nightly - that's when we found that all the tapes, which had been verifying correctly for years, actually had never really been backing up anything, the backup verification routine it turns out just always said good.

They were able to salvage current projects from one developer's laptop he had brought home (they disciplined him for having a source tree on an unauthorized machine), but 20 years of archived projects were permanently lost. A lot of good source control did there.

"Once in the workplace, a new guy somehow managed to erase everyone's source trees by getting onto the source server and deleting everything there."

That's mistake No 1. Why did a rookie have write access to your source control repository?

"He was trying to undo a mistake he had checked in and didn't want a record of it and typed rm -rf * the wrong way. No problem, all was backed up on tape nightly - that's when we found that all the tapes, which had been verifying correctly for years, actually had never really been backing up anything, the backup verification routine it turns out just always said good."

That's mistake No 2: no working backups.

"A lot of good source control did there."

Umm, your problems started a bit earlier than that.

It wasn't my repository it was theirs. This is a story from my days working for the man. I didn't have any stories where source control saved the day, so I pulled out the one where it was involved in a disaster.

Backups were verified to work, they validated after every save.

Doesn't mean squat of course.

Is this really a widespread problem, or is it just an issue for the less motivated students?

The shop I work in occasionally hires C. Sci. undergrads in their senior year, and they all seem to know either SVN or CVS at least well enough to pick up updates and check in their changes. Several of them have worked with Git, which is more then I can say about myself. About half knew Emacs or Vim pretty well, the other half favor Eclipse. None of them took a course in SCM, any more then they took a course in Emacs or Microsoft Word.

About backups.

What should be done, and a friend's company does this, is that periodically, a backup of the repository is restored to an idle machine and builds are actually performed, to verify that the backups are really good.

Most places run "backups" and just hope it's ok.  The backup media are never actually looked at.

+1 Scott

Version control was never directly taught in the Computer Science cours I did - but then again neither was using vi or emacs. You were expected to be able to pick things like that up by yourself and it was left to individual choice as to what editing and build tools to use for actual development work.

Propert Computer Science courses are *not* vocational training courses for programmers.

Clearly they don't teach how to spell either!

My point about branching and merging is that it's something you don't (or at least shouldn't!) do very often, but it's something you need to be aware of once you get out into the trenches and develop software for real. You might not be able to practically demonstrate it, but there should at least be a demonstration of the fundamental issues you can face.  (My apologies if that seems like waffling; I can't think of any specifics).

Most of the time, I have two branches - trunk (anything goes) and release (either shipped or a candidate to ship - treat with kid gloves). The only things that go in "release" are carefully reviewed and tested bug fixes. Occasionally I will need three branches to support a paranoid customer who refuses to upgrade ever and thinks IE6 is cutting edge for their department (banks are good for this), but I try and keep that to a minimum where possible.

The argument about version control being useless because somebody couldn't do backups correctly is not only a strawman argument, it's almost a clichéd strawman pinched straight off Eric Sink's "Source Control HOWTO" (http://www.ericsink.com/scm/scm_branches.html). "Nelly has a friend who has a cousin with a neighbor who knows somebody whose life completely fell apart after they tried using the branch and merge features of their source control tool.  So Nelly refuses to use branching at all." You could do "version control" by renaming old versions so they end in '~' without going anywhere near any SCM system and still end up with the same problem. "My implementation was broken so everyone's must be" is a weak argument, in my opinion.

I agree that writing a SCM system is an interesting CS project, as there are a variety of ways you can trade off space and performance for storing the differences between versions of data.

@Ritchie,  um, you can call it a straw man, but I gather you never had many discussions with people about version control and why some people who make decisions in development organizations don't use some of the mode "advanced" features...

Many people are scared - especially team leads or projec managers - that the horror stories they heard (about Source Safe for example) will come and bt them if they try to branch a Perforce repository.  Totally unreasonable and paranoid, yes, but it happens still. 

Also -  Source control  IS NOT BACKUP.  backup is not source control - they are two different things.  And, as someone else pointed out, backup is useless - it is the RESTORE functionality you want.  Getting halfway through the backup/restore process is useless.

I've not even seen a consensus or even a good explanation of how to structure source control in terms of branch/merge design for releases, or even directory structures.

Heck, there's the same problem with makefiles. The basic makefile design is fundamentally broken, which is well known. The fixes, widely used in professional open source projects,  are highly unobvious. Few students if hardly any understand how to set up a system of makefiles for a project, and doing it right is something that takes weeks of study or a few days of mentoring from someone who has done it. This is still technical information that probably does not belong in a CS course. One solution is to use an IDE, but that's tends to be a proprietary solution, and open source project prefer not to be locked to a particular IDE (with good reason), so they use 1972 era makefiles.

Perhaps this belongs in a masters in Software Engineering program that deals with project management, estimation, metrics, source control, makefiles, etc.

That should be a program that an employer pays their employee to take in preparation for being promoted to a new project manager. Persons without both work experience and an undergraduate degree in CS, SE or CE would not be allowed to enroll. Such a program could be run by a private technical school, there is no reason for taxpayer money to subsidize this level of advanced trade school that is only of value to those who are already employed.

students tend to do small one off projects that are done and never looked at again when they are turned in.

you are not going to see the important of version control if you do that.

"The argument about version control being useless because somebody couldn't do backups correctly"

Since no one said that, please take the straw man and stick it where the sun don't shine. I am so damn tired of all the fucking strawman argument bullshit on this board where someone will lie about what someone else said in order to make a point. It's fucking dishonest.

Version control is useful for several reasons and I use it on all projects. A properly designed version control system is also extremely easy to use and how to do so can be learned in 5 minutes or less. Therefore, it is not necessary to have a class in it. Even if it was complicated, classes in something like this would be inappropriate use of UNIVERSITY time, though private trade schools like ITT are free to teach whatever they want.

Five minutes, Scott?

Get real.

I fought with a source control system and finally got my code in it.  It was rather more than five minutes.

If you already know how to use  it, it might be five minutes, but the discussion is not about those who already know how to use it.

Sincerely,

Gene Wirchenko

First job out of college.

"We have a source control system here that keeps changes to the code synchronized between the developers machines. The command to get a copy of the project on your machine is XXX. Now when you want to edit a file, you have to check it out first with the command YYY. And when you are done editing, check it back in so others can use it with the command ZZZ. When you do this, you can describe the changes you made like so. Any questions?"

But you are right, when I said 5 minutes, I completely misrepresented the situation. I was taking into account the possibility that the new developer is mentally retarded. For someone of average intelligence, it should take 15-30 seconds to learn it.

Yep. I don't expect a recent grad to understand branching & merging, or strategies thereof, but I do expect them to be able to pick up the concept of get-latest, check-in, and abandon-changes pretty quickly.

"We have a source control system here that keeps changes to the code synchronized between the developers machines. The command to get a copy of the project on your machine is XXX. Now when you want to edit a file, you have to check it out first with the command YYY. And when you are done editing, check it back in so others can use it with the command ZZZ. When you do this, you can describe the changes you made like so. Any questions?"

The whole fun starts at the merging stage.

The only problem with new grads not knowing (version control, style guides, best practices) is not that they're ineducable or that the concept is hard, it's when they don't think doing things the right way will matter "just this once".  Or that you are really cramping their style and they can't do things as quickly.  Once you break them of that particular disorder/mindset, it's no problem.  It's not the learning that's the problem, it's Precious Programmer Syndrome.

Students do need to learn to use version control because:

1. Any project that takes more than an hour or two will go through a series of revisions. It's really helpful to be able to keep track of these stages and be able to backtrack if necessary.

2. It actually takes a long time to learn a version control system fully. In fact, there are many aspects of the version control systems that I use (Subversion, Perforce and Git, for various clients and in my own company), that I will never learn. But the rudiments can be picked up quickly. Good version control systems can be downloaded for free and installed in a trice.

3. When the student starts his or her first job, it will definitely help to at least know what version control is, and what it can do.

To anticipate some criticisms of my credentials: no, I didn't do Computer Science at univ; but I have used source control on small semi-throwaway projects and benefited from it. I've been coding for just over 30 years with quite a lot of success; I've used source control for exactly half that period (why not before? I have no excuse: just a slow learner I suppose; and you couldn't just download SVN in those days). I always have trouble with branching. It seems very hard to me; but I accept that some people find it easy. And I can see why it's done.

In my own company (CartoType) we use Subversion hosted by CVSDude, which provides a backup facility as well as the hosting ("Backups taken every 10 mins to 3x offsite datacenters"). So, if you use this sort of service, backup and source control do come together. They are not logically the same thing, but it's as easy for a hosting service to provide one as the other.

On another subject, can we try to keep it polite on this discussion board? People can have honest differences of opinion without descending to abuse and swearwords. At least, some people can.

That whole article was a case of an employer thinking that the world owed him something.  It is true that it would be nice if employees came into your office knowing everything they needed to know. It's also true that it's never going to happen.  We're talking about shiny new programmers here.  The existing schools aren't failing either the students or you.  You're looking for something that doesn't exist--an entry level programmer with four years of industry experience.

Let's take an analogy from one of my hobbies, woodworking.  One of the key tools I use is a plane.  They're wonderful tools for getting things done, in experienced hands.  They're even pretty decent in my hands.  It would be really swell if these tools could show up, out of the box, ready to use.  But they never have, and they never will.  Even when you buy the newest, shiniest, most expensive plane, you need to sharpen it and shape the blade according to your use.  There's no possible way the manufacturer (almost always woodworkers themselves) can know what I'm going to want.  Everybody uses a different angle for different woods, some people grind the blades to have a curve to them, and if they are curved everybody wants a different curve to reflect the uses they are going to put the blade to.

Compared to a programmer, a plane is a very simple tool.  So if I have to adapt the plane to my crude uses, why wouldn't I also have to train a programmer to the way I build software?  I can reasonably expect that they're going to know C++ or Java or whatever language the school taught.  I can't reasonably expect them to know my version control or defect tracking procedures.  And it would be the worst kind of naive to think that a student, whose longest term project to date must by nature be limited to fifteen weeks, would have ever seen a need for serious defect tracking or revision control. Those are things that require long term projects with multiple releases to pay off.  That might be a bit of a challenge to do in a fifteen week class.

If employers feel that this kind of thing is important, that it's crucial to their business, they need to pay for it. Traditionally that's done by on the job training, because on the job is the only place you'll find realistic software life cycle issues.  But it could theoretically be managed by a trade school.  There isn't a huge market for that trade school just at the moment, but if employers think that it's important, they should pony up the money and start that kind of school.

This isn't pie in the sky dreaming here, either.  General Motors had a serious problem hiring new engineers and managers who understood the issues of a real manufacturing operation.  While they probably complained loudly about it, they were ultimately forced to create their own school which could produce the kind of people they wanted to hire.  It used to be called General Motors Institute, but now goes by the name Kettering University.  And it has always worked by the simple expedient of putting students in the field to work on real projects.  They get a good four year degree (if rather narrowly focused), and alternate quarters between the classroom and the field, with all four years spent with the same employer.

So my advice to those who can't find the people they want: stop complaining and start doing something about it.  Instead of complaining, create the school that produces what you need.  Not an ivy league school, but a straight up trade school that puts students in the field in their first year.

"... it's when they don't think doing things the right way will matter "just this once" ..."

That's the key point right there. "Precious Programmer Syndrome" is a good name for it, too. If I complain that students aren't taught source control, I'm not talking about the semantics of a particular tool. What I mean is that they should be taught why it's important.

Second issue someone brought up is branching and merging. This is another one that could do with some theoretical understanding. There are different practices:
A: work in 'main', create a release branch
B: work in a branch,  check in to 'main'
C: concurrent checkout
D: locking checkout
E: various combinations of A, B, C, D, plus maybe F, G, H, I ... etc.

Most people I've worked with don't think in terms of pro-and-con of various approaches. They just like the way they learned to use it, and everyone else is wrong. Maybe if they were taught, "In these circumstances, method A has the following advantages, and the following disadvantages," they would have a better idea what to do with the local VCS tools.

To me, VCS is like a database. Sure, the syntax can be picked up in a day. But there's a bunch of theory that makes it much more productive than it might otherwise be.

Final point on this, is that people keep saying, "That's something you'll learn in the first day on the job." But think about how many people are "the IT guy" at smaller companies. Who do you think is going to teach them about version control? If they already know the importance of it, they can pick up the syntax. But where do they find out what they "should" be doing?

@clay, you said -- I'm sure you remember ;)

"So my advice to those who can't find the people they want: stop complaining and start doing something about it.  Instead of complaining, create the school that produces what you need.  Not an ivy league school, but a straight up trade school that puts students in the field in their first year. "

It's the dichotomy of discussion here, people complain about a BsCS not being a degree designed to create 'computer programmers' and then cry when these self same SW Engineers don't know how to use subversion and vi.

You can't have it both ways folks.

BTW, I'm one of Clay's creations, a guy who took two years of PROGRAMMING 25+ years ago and is now at the top of the craft in the company I work for.  Somedays I wish I had the Bachelors (Masters/PhD), but most days I'm pretty frickin pleased with myself for having accomplished so much with such a small investment (of time and money) before my career began. 

Note that I've spent thousand of hours since then learning everything I needed to know to get my job done - and done well, probably enough (externally) to get that 4 year degree.  But, it's safe to say, that at nearly 50 years of age, 2+ years of full-time college isn't in the cards for me.

schlabnotnik: "Note that I've spent thousand of hours since then learning everything I needed to know to get my job done - and done well, probably enough (externally) to get that 4 year degree.  But, it's safe to say, that at nearly 50 years of age, 2+ years of full-time college isn't in the cards for me."

Different strokes.

I turned 49 last week.  I will be graduating with a BCS in April.  I will be glad to have it over with.  I have learned a lot of neat stuff, but I do want to DO.

Sincerely,

Gene Wirchenko

Gene,

Congratulations!

I'm not convinced that not having the degree is the right thing to do (though my wallet would disagree).  I can tell you, beyond a shadow of a doubt, that my son (who graduated May 2008 with a BsCS) is WAY better prepared to develop software than I was even ten years ago.

But, I think part of that is that he may grok this better than I do -- and I'm no slouch ;)

Again, congratulations, I may still join you someday.

To schlabnotnik:

To confess, I sometimes wonder if I am wasting my time.  With some of the courses I am taking, I already know a great deal of the material.  I mean that I know enough that there are whole sections that I could teach.  The problem is telling when this is.  Something that looks straight-forward can be deeper than it appears at first.  That is a lot of why I am continuing.

I definitely have a different attitude and awareness level than most of my classmates.  It is bound to happen when I have about as much experience as the rest of the class combined.  I do things in my own way, a professional one.  Sometimes, it is almost as if I am taking a different course from my classmates.  My questions and concerns can be radically different from my classmates'.

Sincerely,

Gene Wirchenko

Gene,

Your experience is just what I would expect.  Given the breadth and depth of our knowledge, these are the issues that will be addressed in any 'scholarly' pursuit.  And, I'm not surprised that you find some topics deeper than you expect.  Syllabi are not always the best indicator of content (and certainly not quality).

Thanks for you insight.

schlabnotnik: "Your experience is just what I would expect.  Given the breadth and depth of our knowledge, these are the issues that will be addressed in any 'scholarly' pursuit."

And yet, the material does not seem scholarly to me.  I suppose it is a matter of point of view.

"And, I'm not surprised that you find some topics deeper than you expect."

A few times, people have asked me if my degree is turning out the way I expected.  They have been shocked when I replied no.  If I already knew it all, I would not bother with the degree.  Since I do not, I can be surprised (sometimes pleasantly, sometimes not).

I admit that I sometimes^Woften dig.  With my experience, I have a big shovel.

"Syllabi are not always the best indicator of content (and certainly not quality)."

And what about course calendar descriptions?  They are so compressed that my joke about a general course syllabus is one that reads "At the end of this course, the student will be able to understand the course catalog description of the course."  It is something to think about when deciding which courses to take.

"Thanks for you insight."

And you for yours.

Sincerely,

Gene Wirchenko

I definitely think that source control should be taught. It may not be worth a whole semester, but perhaps a week or two. Maybe one credit.

There are so many ways to screw up once you get beyond basic checkout and commit.

Most companies during orientation don't seem to cover much beyond the basics. "We use SVN, here's an account and the URL, read the manual, have fun!"

Proper merging should definitely be taught. There have been several times over the last ten years that I've seen a critical bug fix get lost in a merge. I've even done it a couple of times. There's a lot of useful tricks that only seem to get picked up by experience with major screwups that it would be better to learn in a class.

And that leads into things that probably shouldn't be done. Like refactoring a bunch of code into five new pairs of implementation and header files. That may be great but all bug fixes now have to be carefully pulled out of the new or old files and manually merged into the new/old branches.

Or to never ever mix reformatting/whitespace change commits with code changes.

As I said, lot's of stuff.

CS degree has nothing to do with code.  It sometimes happens to be the way that ideas are presented, but it is like a journalism school teaching people how to use a typewrite or a steno pad. 

Additionally - if you teach one particular technology then it will QUICKLY become outdated. 

I doubt MBA schools have a course on how to make pivot tables. 

A survey/seminar or a "practical methods" course might be useful, but, again, it is really a simple thing to teach on the job.  It is also much more relevant to have it done on the job since each company/group have different process for development.

Do you propose to show students how to use a defect tracking tool as well?

Jonathan Briggs: 'Most companies during orientation don't seem to cover much beyond the basics. "We use SVN, here's an account and the URL, read the manual, have fun!"'

That is about what happen to me.  A different program but about the same level of help.

"Proper merging should definitely be taught. There have been several times over the last ten years that I've seen a critical bug fix get lost in a merge. I've even done it a couple of times. There's a lot of useful tricks that only seem to get picked up by experience with major screwups that it would be better to learn in a class."

I have been doing Tt long enough that I know that these sorts of things can happen.  I wish more would catch on.

Sincerely,

Gene Wirchenko