Response to article: “Version Control: Important for Individual Projects?”

Introduction

This is a response to the article “Version Control: Important for Individual Projects?”.

The article tackles a subject that should be of great interest to all the students in this course. Each and every one of us should ask ourselves the question in the title. Hopefully all of us who have already finished the implementation part of our thesis project have used version control. The ones that will be doing their project next year should start thinking about the advantages of using version control.

In this article I will emphasise both my agreement and disagreement with the original paper. Where necessary I will support my statement using examples from my own experience.

I have recently finished an Industrial Placement at a software design company. This placement represented my master thesis project and I was thus the only developer. The company I worked for was using version control for every single project and they advised me to do so with mine. After this experience, I strongly believe that version control should be used in any software project including the ones in which there is only a single developer. Actually, as Saikat Basu says in his article [1], version control should be used in “anything that has to do with typing an alphabet on a document”.

Discussion

I agree with the author with respect to the fact that version control is “essential to maintaining an organised structure” by allowing all team members to work on the same source code from different locations. However, it is important to emphasize that this is an advantage of having an online shared repository more than using version control. During my time at the company I was able to see how people on different continents were successfully using an online shared repository combined with version control to work on the same project. Moreover, it was a very good way to share ideas and documentation. Although version control allowed them to keep track of changes and updates, this would not have been possible without a shared copy of the project.

The author states that “These advantages do not apply for an individual developer”. It is not clear if in this context the individual developer can’t take advantage of using version control or an online repository. I believe that having an online repository is useful even for individual projects since it allows you to have a distributed backup. Some people prefer to use the company’s computer while they are at work and their own when they are home. Having an online repository will allow you to work on your code from different systems.

I agree with the author that reverting back to older working versions is very useful for any type of project; individual or teamwork. Throughout my project I was often updating code, improving algorithms and adding new features. Having older versions backed up assured me that even if my changes break the code I could always return to the original state of the project. I personally comment out code that I don’t want to use until I am sure that it is not needed anymore. But I have seen people that simply delete their code before writing the new code so it doesn’t clutter their screens. Source code control allows them to have a clean screen and simply revert an old commit rather than trying to remember what the working code was.

“Keeping track of who did what” is indeed a very useful feature of version control especially if the team is very large. I have seen in the company how easy it was for a developer to track a colleague who made a certain change he was interested in. They were able to discuss the problem, modify it together or even revert to the old code without inconveniencing the entire team. It is true that a lone programmer would not have this problem but there might be the case when you want to share your code with someone else. For example, I shared my code with my boss once to help me fix a bug. Later on I broke his code and was able to check the project history and see where the bugs were introduced or revert to his working version.

I agree with the fact that version control allows you to “expand your project in the future”. In my case version control enabled my boss and his team to continue working on my code after my departure. They can now experiment with new features without interfering with my working code. They can even maintain multiple versions of the developed software product and easily check the differences between them.

It is true that merging multiple changes to the same piece of code using version control “can be a pain and cause aggravation”, but it is better than one person doing all this by hand. I disagree that this is not the case in an individual project since merge conflicts between multiple branches can still happen even if you are the only developer. The best part of being a lone programmer is that you don’t have to over think the merge and it is less likely that you will have to solve the conflict manually.

Yes, familiarising yourself to the version control system is a ‘”point of stress”. Even though the company I worked for had the source code control set up it still took me some time to get used to it. If they didn’t have it set up I would have taken the time and done it on my own since version control does indeed make your life easier.

Conclusion

I think that version control should be used in any software development project irrespective of the team size. For the student working on his thesis project, using version control with an online repository will give him one less thing to worry about: losing or irreversibly breaking code. Moreover, you never know who you will need to share the code with or if it will be used in the future.

References

[1] Saikat Basu, “Not Just For Coders: Top Version Control Systems For Writers”, May 2013, “http://www.makeuseof.com/tag/not-just-for-coders-top-version-control-systems-for-writers/

One thought on “Response to article: “Version Control: Important for Individual Projects?””

  1. Edited:
    Good points about version control systems. I also think that any project, even single-developer one, should use a VCS. Especially, if the project could be used any time in the future (even if not being developed for years).

    My reasons overlap with Yours, but there are even some more:
    – you always know what you did last on the project (even though it could be few years ago) through history listing;
    – with remote repository, you may swap computers and still work on the newest version of the code. Before I started using VCS, I had tendency to pack the files into archive and send them to my email, so that I could work on them somewhere else. And it was not always successful, especially if I did it just at the very last moment (missing files, unsuccessfully sent messages, or “which archive is the correct one”? issues);
    – it happened to me for few times, that if the project hadn’t used version control and hadn’t been used for a long time, it got forgotten and wiped out when I changed a disk, did some reformat or replaced my computer. Some of my projects got lost this way, unfortunately. Having a remote repository (presumably), which is a specialized storage for your projects only, will make sure that they are there for you.

    Learning curve… e.g. I find advanced features of git hard to use, but basic ones like stage, commit and check-{out,in} – these are just one-liners that don’t require thinking. It’s a good start anyway and still gives a multitude of benefits, especially for a single developer. Additionally use of GUI tools, e.g. git-cola help not to get lost (I use it very often for selective file staging, while executing other command in terminal).

    As to the point of setting a repository… if you don’t mind storing it on services like github or bitbucket, it takes as much hassle as setting up an account there. However, if you want to have your own server, it isn’t that much more complicated either. At least in a setup I did it – for my purposes I used gitosis (http://git-scm.com/book/en/Git-on-the-Server-Gitosis). It requires you to:
    – perform “installation” (run the script),
    – create only one system user (git user?) – if you don’t administer the server, it’s only one simple user – ask administrator to create it for you;
    – define its repository directory;
    – add users in the gitosis configuration file and provide their public keys. Each of the users may have different access privileges to the projects in repository directory, which ensures security.
    It worked for me many times and I encourage others to have a try (for instance on virtual machine or some VPS).

Comments are closed.