Comments on: (not) Cargo cult programming, source control, communication, and lack of it all

By: Tony

Tony — Sun, 20 Apr 2008 19:10:53 +0000

Or, you use an actual source control system (such as Subversion) to keep everybody’s files in sync and up to date. It also keeps track of all the changes, so you know who changed what, and can roll back to previous versions if things get horribly broken.

By: Geekhall.net Admin

Geekhall.net Admin — Sun, 20 Apr 2008 18:26:37 +0000

Well, as usuall – keeping all files clean and up to date with everyone is hard, tha’s why, when we sit to any projects we do not start until everyone have a Beyond compare application and all files are the same

By: Gorge

Gorge — Fri, 28 Mar 2008 06:47:45 +0000

Sounds like a freaking nightmare Noam. lol Funny read though. Dan;s last line was the classic of course. :O)

Btw, I have found every programmer to be very arrogant about his skills.

By: Noam

Noam — Mon, 24 Mar 2008 14:38:19 +0000

I do agree it’s a weak test, but it’s the bare minimum. Ideally, you should definitely make sure it also runs, then do testing of the area you changed to make sure nothing was compromised, and THEN have your buddies do a code review. Some places will enforce unit test passes before committing.
But schoolwork is another story, in that the projects are small and time is volatile. Things can come up that don’t really allow for a strict routine. If you have another assignment to do and you want me to take on your code for a day, then at least don’t put me through a million compile errors. That way, I won’t mind dealing with your new segfault nearly as much.

By: Tony

Tony — Fri, 21 Mar 2008 01:26:29 +0000

Noam, we’ve got to take some classes together. I figure that instead of Java, I can write my code in jRuby, and then splice the bytecode into the project

Also, compilation is a weak test, but checking in code that doesn’t as much as compile is simply negligent.

By: Noam

Noam — Thu, 20 Mar 2008 20:15:56 +0000

If at all possible, make sure your code compiles before you commit. I’ve avoided a lot of trouble by enforcing that rule. Breaks can still happen, of course, but not as often (unless everyone is working on the exact same piece of code and merging multiple changes there… and if that’s happening *often*, you’ve got other problems )

By: Noam

Noam — Thu, 20 Mar 2008 15:07:16 +0000

“…though doing that in a completely different language is new…”
Just for fun, I’m going to put random sections of COBOL into my next group project and see how people react.

By: Aziz

Aziz — Thu, 20 Mar 2008 12:45:47 +0000

“Fuck, fuck fuck fuck fuck” about sums up a programmer’s thoughts much too often, Dan

By: Dan

Dan — Thu, 20 Mar 2008 06:11:10 +0000

Well some good news is that we have manged to get everything in C and amazingly the svn set up right. However it took a lot of arguing and hitting my head on the wall, table, what ever was in range.

Tho unforntely a lot of the members of the team are still working under the method of starting with some random demo or example online and just throwing lines of code in in till it works. This is leading to an extermaly messy and hard to work with code base and almost random results at times and the oringal programmer of the bugged code having little or no idea how to fix it as they do not relay understand how it works them self.

Things are getting better as the ones of us involved in the project who have more experience have been keeping on the rest to use better partices and are working with them more closely.

Personally i blive a big part of the problem is that university do not teach some of the fundamentals that are needed in real life projects, like how to use and set up an svn server, or how to code in a large project that is broken in to several sub teams or even how to do good tests on your code before you check it in. Also the Cargo Cult Programming method is never fully weeded out as students can just get by, by using it for small sized assignments where the problems are minimal but can not translate to big projects or working in teams.

Another issues is the arogence that seems to come with being in a tehcnial field. A lot of us think we are right about our methods or solution even if we have no proof or valid source for this blife. This can lead to cirucalr arugments and the use of tools and methods that can over complicated the project well adding nothing but bugs and complications.

I would like to add that not every one in this project i am yelling about in the artical are idiots and they are all good guys with the best of intentions but could do with a bit more experience in groups (including my self). The comments where made in a very emotional state when the project looked it was head to ceritent failure and no one was realy talking to each other. Now the project is getting back on track and using better methods, in the end it was a good learning experience for us all (i hope).