Hacker News Reader

Comment by jiggy2011 | Hacker News Reader

jiggy2011

So, how does one work at all with multiple programmers and no version control?

Are you creating patch files and manually merging them (like Linux used to do)?

Or are you just using a shared FTP and keeping a spreadsheet of who is using which file at any particular point?

The amount of discipline and organisation required to use either of these methods would appear to be far higher than that required to sit down for a few hours to learn a basic VCS like Subversion using a graphical tool.

View on HN

The first thing I do when starting a new project is get everyone on git. If the project is far along and is using svn, I can live with that ... sort of.

The next thing I do is explain that I will be spending more time for coding upfront because I will introduce testing into the project.

These are not negotiable.

Do you retrofit tests to old code? If so how do you deal with spaghetti that at first glance appears almost untestable, insist on a refactor?

They usually want me to fix old code ... exploratory tests are really the only way to do that.

It helps that I write integration/functional tests almost exclusively (unit tests are imho useful only for algorithms, which is not what I'm usually working on).

I mean, I can either spend 20min writing a test, or 5min clicking around the app every time I change something ...

I'd be interested to know how you sell git to your clients.

I have listed all the positive benefits of version control in detail to my clients and still have the idea rejected due to it being an "unnecessary complication"...

If the opportunity arises, try the following approach: Tell your client " I use some very specific tools for my work as they increase my productivity and efficiency, and as part of the work i deliver to you, i'd like to continue using those tools to deliver to you. You'll receive multiple benefits as a result, and i can name them if you wish, but don't wish to bore you with technical details"

Just try it. Not making any promises, but i think you'll have better luck if you do. Sounds like you're either framing things wrong, or allowing certain people to make the decision when it should be yours to make ;-)

I suppose it depends on if you're trying persuade another programmer or the end customer.

The way it is framed seems to suggest that they have an existing (probably solo) developer who is used to not using version control and is frightened by the thought of adding new tools and processes.

If you introduce such a person to version control it will necessitate them spending some time to learn the system which they may be defensive about since they see it as some outsider encroaching on their territory.

In such a case the best bet might be to follow their method until you hit some situation where there is a problem or significant reduction in productivity as a result (shouldn't take long) and then demonstrate the virtues of using source control.

If on the other hand it is a non technical person who is making specific dictates about source control then that might raise another set of red flags.

Yeah - When I was providing IT support services, we used to run into a similar kind of problem all the time. In the end we realised that we were going to execute in a way where they had no option but to use the tools that we wanted. We at all cost avoided getting into a debate with internal IT staff, and as for the client gave them only one option which was to do things the way that we wanted.

Your method of using appropriate timing to introduce new tools is also what we employed and works very well.

Clients don't really care what tools I use. I just tell them what I'm going to need to provide the guarantees we both signed in the contract.

Other developers can be trickier, but it's very simple to get logical people on the path of version control if you override their changes once or twice. (usually unintentionally)

Actually, the only time I've encountered zero version control, I simply refused to start working until git was introduced into the project.

I once started at a job where their last programmer had just quit. When I started, my new boss explained to me that I had to check out files by telling him which ones I needed and we updated the production server with me emailing him the modified files.

I set up SVN the first day.

One person works on any one file at a time. To make sure you're working on the latest version you have to remember to download the latest copy from the live server.

No I'm not joking, and yes I know how unbelievably terrible this is, but it does happen.

I worked for a very (very) large french website that does not use version control internally.

Mostly because most of the code is owned by a single guy and he does not see the problem with that.

Note the 'ed' at the end of 'work'.

I worked for a small company for the last few years, and although the company was small the codebase was quite big. Despite my many attempts out of desperation, they wouldn't listen. And the irony is, I'm not even a developer - But i knew it was needed.

The excuse cited was always that version control was impossible with languages that compile (we were on .Net) - I'm sure there's a response to that, but I didn't know what the response was, and just decided to leave in the end (amongst hundreds of other reasons)

I'm not even close to understanding why version control is impossible with compiled languages. I use version control with Java/Groovy all the time.

Version control works best on plain text documents, but you can certainly check in binary assets to version control repos. I've done it even with CVS back 12 years ago, although IIRC it was a pain - SVN was somewhat easier, git is simple (re: binary files).

Actually, the simpler response is the .NET ecosystem has their own version control stuff (Team Foundation Server at very least - http://msdn.microsoft.com/en-us/library/vstudio/ms181368.asp...).

Software devs not using version control should set off as many alarm bells as an accountant that tries to keep everything in their head, or doesn't keep receipts. Obviously it set off those alarms for you - it's just sad that the developers themselves didn't see it.

Wow, thanks for the insight. I had no idea!

You're right. It did set off alarm bells at the time, but i kept having doubts since i myself am essentially a non-developer and was unsure if perhaps my argument was weak.

Now, especially after having read your response not only am I very relieved, but am realising that I had more admiration for these developers than they deserved.

Yes, it's usually best to keep compiled files out of version control unless you have a specific reason for doing otherwise. Most IDEs will generate seperate src and bin folders which makes this easy enough. Just initialise the repo in the src folder and it will have no knowledge that the compiled files exist.

Phrased another way, if compiled languages were indeed incompatible with source control then that would be a reason for discounting doing serious development in compiled languages altogether.

You can also point out that git was designed specifically for use in a compiled project (the linux kernel).

Reply on news.ycombinator.com