Article: Top 5 bad excuses for not using source code control

[Jim_Kring]

[Note: cross-posted]

Here's another article with some of my thoughts on source code control:

• Top 5 bad excuses for not using source code control

Thanks for taking the time to read it. As always, your feedback is appreciated and encouraged.

-Jim

[mikeporter]

Great article Jim, but you missed my personal favorite whine:

"...but I'm an artistic programmer. Source code control will stifle my creativity..."

First, God save and protect me from "artistic" programmers.

Second, the ideas that SCC stifles creativity is simply silly - as anyone who has actually used it will attest.

Mike...

[Timothy 123]

Hi,

This is a great article. I had used scc with labview 7.1 for my project, but stopped using it in 8.2 since there was no built in source code control program. You had to rely on a third party tool. We were planning to use a tool like Perforce. From your article, you say that subversion and cvs will also work. Do these integrate into the scc in labview as well.

-Tim

[mikeporter]

Subversion is a perfect tool for use with LV. For example it implements an extensible diff'ing capability that can link to the VI comparison capability of the Pro edition (if you have it) but it is usable with any edition. Add to that it's free (in the philosophical as well as the financial sense), explorer integration through TortoiseSVN and you have an all around winner.

Mike...

[Jarrod_S.]

---

mikeporter wrote: Great article Jim, but you missed my personal favorite whine: "...but I'm an artistic programmer. Source code control will stifle my creativity..." First, God save and protect me from "artistic" programmers. Second, the ideas that SCC stifles creativity is simply silly - as anyone who has actually used it will attest. Mike...

---

I hope you're not referring to my famed, artistic habit of signing my initials into all my VIs using the error cluster. Don't censor me! Just kidding (or am I??)

Message Edited by Jarrod S. on 06-18-2007 11:47 PM

[Jim_Kring]

Be careful, Jarrod, or you're going to give LabVIEW programmers who use a Mac a reputation that will be hard to shake

[Jim_Kring]

Mike,

> Second, the ideas that SCC stifles creativity is simply silly - as anyone who has actually used it will attest.

I agree completely.  It is a well know fact that good tools such as source code control, automated unit tests, daily builds, peer review, and other software engineering activities actually improve creativity, because they give programmers more security that their changes won't break the code.  Specifically, programmers who are confident are more likely to be creative and actually solve problems -- source code control gives you that confidence.

Cheers,

-Jim

[Jim_Kring]

Tim,

> This is a great article. I had used scc with labview 7.1 for my project, but stopped using it in 8.2 since there was no built in source code control program. You had to rely on a third party tool. We were planning to use a tool like Perforce. From your article, you say that subversion and cvs will also work. Do these integrate into the scc in labview as well.

As Mike said, TortoiseSVN is a great tool that integrates with Windows and really obviates the need for much integration with the IDE.  However, integration with the IDE is still nice to have.  PushOK makes both a subversion and CVS SCCAPI-compliant plug-in that will work with the LabVIEW IDE.

Thanks,

-Jim

[drval]

This is also a cross-post...

I'm going to disagree with the fundamental premise of this article -- I personally have NOT found any "added value" in using an off the shelf Source Code Control product. I am (essentially) a single developer (ie not part of an extended team) and, while I make use of consultants at times, the majority of those kinds of interactions occur episodically or in re: to small units of code. I use three different development systems and frequently change those out (any ways every 2 months); and am now simultaneously developing in Vista and XP, with one of my system being XP running within Parallels. I have several different physical backup that I use, including china copies and I rotate these on a scheduled basis. My major project consists of over 1400 subvis and I am currently engaged in a major refactoring/restructuring process in anticipation of the next major release. Partly this is because of the nature of the project itself, partly it's because of demands imposed by both Vista and the necessity of maintaining legacy support of XP-based deployment.

Now I'm not trying to imply that any of that mandates not using SCC per se (ie not using a particular SCC software package) but I am trying to give a bit of context for my comments.

I personally have found that the use of Subversion actually slowed me down and led to my losing some work. It did not help me and, while using it, I actually felt far less secure in my control of the actual source code and frequently quite frustrated with the overall process. Now I'm sure that others can argue that this was due to my unfamiliarity with Subversion itself -- I'm definitely NOT saying that it's bad in any way -- but no matter how true that might be, my lack of familiarity with Subversion misses the essential point that, in my case, it simply didn't add value to my work flow. And taking time to have it POTENTIALLY add value to my process wasn't a very effective use of my time at that piont. It just complexified my work enormously without giving me any direct benefit. As a contrast I have found the LabVIEW Project to be quite useful in a number of ways -- not so much as SCC per se but it is a "new" tool, with which I was originally unfamiliar, but have gradually grown to find directly beneficial and which was intuitively obvious enough to me AS I was learning about it, to be able to make use of it in some ways immediately.

FWIW -- and just to be clear -- I think that Subversion is a very good tool and I know an enormous number of people who use it both in and out of the LabVIEW world. I have and would recommed it to others who want to make use of SCC and don't want to have to pay a lot for that functionality. But it just didn't work for me. I may look at it again in the future -- when I am at a different point in the current work flow and can take time and space to really get to know it -- but until that time, I am reverting to my prior style.

[mikeporter]

As you point out so well, utilizing a SCC tool - regardless of which one - does require a level of discipline as a developer. Not everyone has the required degree of self-discipline.

However, I must address a couple of your comments for fear that someone coming along later might read them and, seeing them unchallenged, assume that there is any truth to them. First, I can't imagine how one would go about losing work with Subversion as it goes to extraordinary lengths to ensure that things don't get lost. I would like to hear about the scenario that led to data loss - as would the Subversion developers. Maybe you have found a hole in the system that the tens of thousands of current users and testers have missed.

Next, the issue of some supposed slow-down in work is really a matter of what you want to focus on: The 2 or 3 things that you have to do that wouldn't be needed otherwise, or the dozens of things that it saves you from having to do. Subversion saves me untold hours of unproductive activity - but then I was willing to take the day or two required to learn how to use it.

Finally, your point that, "...my lack of familiarity with Subversion misses the essential point that, in my case, it simply didn't add value to my work flow..." is logical nonsense. How about taking a little responsibility for your own actions? The truth of the matter is that you couldn't be bothered learning how to use it and are now blaming the tool for its lack of efficacy.

Mike...