How can I maintain code quality without SCM?

Question

I am working in a governmental institution. The technology being used here and the methods for developing software are quite old fashioned.

They have tons of storage space but no appropriate space to keep and maintain applications that are used to automate most of the work here.

The institution would not allow me to use SCM software like GIT or SVN.

What would be the best approach to keep code quality and be able to add new features in the apps later on?

How can I remember changes I have made to the code without breaking it?

EDIT: I forgot to mention, they have network drives for each of the computers and somehow these network drives make or save backups in periods. However if I don't create my own plan allowing to save my work and be able to add new features without breaking the existing code, there is no big advantage over an SCM solution.

EDIT: Since many people suggested portable Git I have to add more info. I tried installing Visual SVN server, but it failed because I don't have admin privileges to install. I also tried downloading regular Git shell, but the firewall or the network settings didn't allow me to access Git download page. I even tried, sending portable Git to my email which is Gmail. Google detected the exe file in the package, and it too didn't allow me to download the portable Git version on my work computer. Another thing I have to mention, the network policy applied to the computers trough the institution do not allow using USB storage devces. You can use the USB ports to charge smartphone or power some gadgets like small speakers. Also as some people mentioned, there are computers on which not even Internet is allowed.

Answer 1

You can loosely replicate the role source control plays with three simple tools:

• Back-up software (Commits/Check-ins)
• Folders (Branches)
• Performing a directory merge between two directories using a tool like KDiff3 (Merging branches)

Basically your workflow becomes:

1. Create a new folder (new branch)
2. Copy files to the new folder (new branch) from an existing folder (existing branch)
3. Make a back-up of that folder (finish creating the new branch)
4. Do some work
5. Make a back-up of the new folder (commit)
6. Do a directory merge from one folder to another (merge)
7. Do another back-up in the other folder (commit the merge)

The more monolithic source control systems, like SVN or TFS, basically do this for you behind the scenes.

---

Now, the reality is this is like a Bus Company telling its drivers that they can't drive buses that have a battery, forcing the drivers to push the bus down hill and then pop the clutch to start the bus... this is terrible and indicates that the current management doesn't know anything about running a bus garage. My condolences.

But at least you can get the bus started.

Answer 2

Although the consensus would certainly be to not work for this company I don't believe that really answers your question.

You can't really replace SCM.

You might not need the usual bells and whistles of a full-blown system. For example, the company may refuse a request for a server, but permit the use of a local SCM. They may dislike git, but permit subversion (or some other versioning system).

There is of course a question: what are your colleagues using, or any previous workers? If you're the first Software Developer they have, then it's your time to push very hard for the resources you need.

In the end, if your company doesn't respect your role and experience and won't permit you the tools you need, then you are going to run into even worse (and more stressful) problems than a lack of source control.

Answer 3

Basically, there is a management problem (your organization don't understand the basics of software development process, e.g. the V-model) condensing into the apparent inability of using minimal present-era workflow, methodology, and tools. This is common (read about Peter's principle).

^{BTW, I guess that recent SNCF railway incident in Paris at end of 2017 have a similar cause (total lack of software culture at high management level, hence blockage of a major Paris railway station for more than a day; of course there are very competent IT teams at SNCF, but they are not consulted on major decisions). I can name several European industries with total lack of software culture and I am sure to be able to find similar things even in the USA.}

The main issue is: are you working alone on your code base, or do you work with colleagues?

If you are working alone, you can use git locally on your computer, and backup your code (and probably even your .git repository) periodically (to that external storage space). Be sure to never lose more than a half-day of work (so back up your data periodically and reliably).

^{(I suppose that you know at least both git and svn and that you know the technical superiority of git; if you are not even allowed to install some tool like git on your work computer you need to have a serious conversation with your boss about that issue: you need the ability and authorization to install external open source tools (and that goes with your responsibility to choose, configure and install them wisely & carefully and without known vulnerabilities)}

If you are working with several colleagues (I guess less than a dozen of them), you need to convince all of them to use a version control system, and you probably need to tell about that to your immediate (and common) boss. He could (probably) decide (or simply implicitly accept) that some machine (perhaps even some old desktop, perhaps even your own desktop) is used as a git server. You absolutely need to set up that server so that the git repository is backed up at least every hour; you cannot afford (and you need to talk to your boss about) losing more than an hour of work of your team.

^{BTW, I love Linux, and I would recommend installing Linux on the machine acting as a git server; then installing git and configuring periodical backups (with some crontab job) is very easy; notice that a git server could run Linux with Windows clients using it. I would even suggest you to switch your development machine to Linux if you can. It is "cheaper" and much more developer-friendly}

But you need to use an SCM. You might ask your boss a different question: should your team use an existing SCM or should it reinvent the wheel and make your own SCM? Bosses are generally against the idea of reinventing the wheel. If you are permitted to reinvent the wheel, tell your boss that it a full time job for at least a year (that will probably make your boss cry, then accept the obvious way) and have fun making your own SCM. In that unlikely case, be sure to study the existing SCM systems, and ask to make your SCM system some free software tool (to be used and improved by other teams).

You may need to prepare (during several days) a precise and specific argumentation for the need of an SCM: first for your colleagues, then for your immediate boss. Be sure to also suggest concrete solutions (like running some git server on some desktop or some "old" server, and backing it up hourly thru a crontab job)

Don't install any software (from outside, even open-source) on your work computer without permission (in most countries, especially for sensitive IT work for the State, installing a software without permission is legally a crime, and you might lose your job or go to jail if you do that .... so be sure to be authorized to do so; perhaps cover your ass by asking a permission in writing, or at least by email).

^{(either you'll need to ask on a case by case basis, or you need to get trust from your organization to be allowed to install any legal software -mostly open source or free software- on your work computer).}

PS. How to technically build, configure, install then use git (from its free software source code) -or most other free software VCS- on a machine (even without admin permission) is a very different question (to be asked elsewhere). And it is possible to install then use git without any admin permission, provided you have enough resources (time, disk space, some C compiler, etc...) for that.

I tried installing Visual SVN server, but it failed because I don't have admin privileges to install.

This is solvable by some specific configuration and compilation of your git or svn from the free software source code of git or SubVersion -not just a binary package- (and also the source code of dependencies); how to technically do that is a different question (but such technical questions should go at some other place). Of course you should ask permission (from your boss) to compile the source code of git before doing it. He will tell you, or you will discuss with him, about the practical details (if he accepts such a solution) regarding transfering that source code from outside onto your work computer.

Answer 4

First thing I would do is identify specifically what the government agency (presumably the IT department) is objecting to. If they have storage space, but no way of hosting VMs for servers, then the problem may be that the IT department is saying no to the SVN or GIT server and that is a big distinction. If the problem is the country of origination--i.e. we don't trust tools created by foreign entities--that is a different problem.

You can run GIT completely within the file system, which I have done on infant projects before I'm ready to do anything with them. GIT also does not require administrative privileges to install.

If you absolutely cannot use Git for whatever reason, then you have a couple of options available to you:

• Educate: By not allowing version control, they are introducing significant risk. You need the ability to back out of changes that prove to be more problematic. You need the ability to save the government money and time, and SCM does that. You need to be able to clearly explain how. You also probably need to do an analysis of alternatives to really drive home the point.
  • One alternative would be hosted Git
  • Another filesystem Git
  • Choose at least one, but not more than two more alternative SCM tools
  • and finally what is like to work without version control
• Go 70s era development: There is a reason that patch and diff were made so long ago (80s). They were the enabling technologies that made version control possible.

What does 70s era development look like? It ain't pretty, but it's how we got started. Applications were much smaller. Essentially they had some common things:

• There was the concept of the gold standard. This was the master source code that had features complete.
• There was a Configuration Management (CM) team. Their responsibility was to get changes from development into the gold standard correctly. This is where you need patch and diff to substitute for the team.
• You worked from a local copy of the source code. You finish a feature in it's entirety and submit it to the CM team for them to integrate. Usually there is an accompanying document so that new files get created and obsolete files get deleted, etc.
• Then you fix any errors from the integration process.
• Before you can entertain another feature or bug fix you get a new copy of the gold standard.

Essentially, it is an error prone process with lots of potential for things to go wrong. The idea of "branching" is easy to implement, but a nightmare to manage. The major issue is that when you have too many copies of the source code it's hard to understand what is the correct baseline for production. For practicality's sake you have to become single threaded.

This is what you need to include in your analysis of alternatives.

Answer 5

Given the constraints you mention in the comments (e.g.: can't get to Git download page, Windows platform, and using Visual Studio 2005), I can see 2 options, both of which I have used before in a similar situation:

1. Use Visual SourceSafe as Emerson suggests in a comment. I worked with a team using VS 2005 some years ago, while most of the rest of the company was using standard version control in Linux/Unix, and they happily used Visual SourceSafe for their CM. It's pretty old-fashioned at this point, but better than nothing.
2. Speaking of better than nothing, I've been in a similar bind myself. If you can't even use VSS (perhaps the plugin is not installed?), and since you say there is plenty of storage space available, hopefully you are allowed to use some of it. I implemented a manual file-based version control protocol. At the end of every work day, I would copy my code base to a new date-stamped directory. If I needed to refer back to previous work (or roll back), I would look at previous dated directories to find the change I needed. Since you have Visual Studio available, within a couple hours, you could probably use VS 2005 to write a simple tool to help you automate the directory creation and file copying.

Answer 6

They have tons of storage space

Are you allowed to use it at your on decision?

If so you could create a file system remote repository which is better than nothing. The downside is that pushing becomes slow while the project is growing because git needs to download the whole repository to look for the changes...

so far the computers behave like ordinary user, forbidding me to install third party software.

git also comes as a portable app so that you can install it in your $HOME or %USERPROFILE% path.

---

As a conclusion: I would not let them forbid me using a SCM¹. I would use it "in private". After all nobody cann tell if your code has been developed with or without being checked in somewhere...

¹) when I started using git some years ago my customer preferred a different SCM which was quite slow and unreliable (which is sort of a NOGO for a SCM after all (o; ). I used git "in private" on top of the other SCM with a "file based" remote on a network share and only checked in into their SCM after a new version of the product had been released.

Answer 7

Your environment

First of all, I would not be so pessimistic like shown in many comments and answers. Yes, this is "stone age", but there are much worse circumstances. If your overall work environment (colleagues, location, pay, interesting programming work etc.) is fine and to your taste, then by all means stick with it. Regarding IT, it is what it is. This does not only happen in government agencies, but also in banking, insurance or wherever there is a very large focus on security, or very old structures.

Inserting an USB stick and running some .exe from there would be immediate cause for termination in other places, so I would not suggest you try to circumvent anything.

Try git once more

Now on your choice. I would strongly recommend git instead of svn for you. If you are doing one-person projects anyways, then git is just a local directory .git inside your application root, nothing else.

Do not ask your boss/IT for an "SCM", but ask them specifically to install git on your machine so you can develop faster and with higher quality. Make it clear to them that you do not wish to push your code to somewhere else, that you do not need a server running somewhere, and that it will not use up significant space or maintenance time.

Git will increase speed and quality for you simply because you can work with more confidence (because you can undo any changes you did) and allow you to work on multiple branches at the same time. I.e., if you are working on a large task, and something comes in that needs your immediate attention, you can just switch to a new branch, quickly fix that, and then return to the long-running task.

Doing it manually

If it just is not possible at all, then of course you can do manual source control. Create manual "tags" by copying your code yourself (maybe create a new directory with the date/time, and a short description of what changed). Keep a Changelog with detailled listings of not only your changes, but also the files you changed, and maybe even more details.

Create "branches" by, again, copying your work, and when it is time to merge back, getting creative using some arbitrary "diff" or "diff3" tools - I don't know if you have any available, you will have to find out.

If all of this costs you a lot of time, then take a good hard look at whether it is really worth it for you to emulate a SCM. If you find that it is worth it, then talk with your boss again. Show him the benefits of your manual SCM (not just "I have a copy of all my old work" but "when bug XYZ happened I was immediately able to find the reason, 5 releases ago"). Then tell them how much faster this would be with git.

Obviously, if this is driving you crazy, looking for a job is always an option.

Answer 8

Sell it to them

You left this comment:

They have a network drive which I don't know how but it creates backups in periods. Yes. I use it and I store my apps there.

Go to your superior and say something in this vein:

Boss, I noticed we have a system where we put apps on the network drive and some kind of service makes back ups and keeps track of the history. It seems to me like we're just implementing our own source control system by doing this. We could probably free up a lot of space and make the whole system a lot simpler by switching to a dedicated source control management system, like SVN or git. We'd get plenty of benefits: simpler back ups of historical versions, tools for understanding what changes were made to files over time (very useful info for debugging), easier ways to undo mistakes, and easier ways to combine different people's changes.

I've used these kinds of systems before, and they're very good at the task our custom set up is performing. It's a lot harder to make mistakes with them than it is our current system. They're also very mature and widely used technologies; these tools have been widely used for over 20 years. And on top of that, we can use the most popular software without paying a dime in licensing.

I'd be happy to help picking a client and a server and to set them up. I expect it would only take [insert estimate here] hours to install it if I can get a machine. Any machine would do, even an old desktop about to be retired, as long as we can access it over the network.

The high level summary here is that you need to put it in terms they can understand and are likely to think is worth it:

• Freeing up resources (hardware and people) for other purposes
• Lower risk (human error, stable technology)
• Increased productivity
• Small cost to implement

Your superiors aren't technical people and they don't care about technical problems. But if you can frame the problem in terms of money and things that cost money, their ears might perk up a little.

Answer 9

I think a lot of people here are missing the "government institution" of this question. Some government networks have very strict regulations on software allowed onto them, and breaking those rules are a fireable offence, perhaps even criminal. I'd push it through management to see if you can get some APPROVED movement on getting the software installed. I wouldn't go cowboy and install stuff myself. If you're running Linux/UNIX, see if RCS (ci/co commands) or SCCS (sccs command) are installed. These are old SCM tools that used to be fairly standard. It's not pretty but better than what I'm about to write below. :)

Since you have "lots" of disk space, create a source tree. What are the basics of SCM on a small scale? Being able to check-in changes, look at what's changed, , tag stuff, and go back to old versions if necessary. One level above the source-tree, create a Makefile or scripts, depending on what you have available, that does the following (these are Linux/UNIX flavored, Windows commands would be different)

make checkin - cp -a source-tree source-tree-date (at least to the minute, if not second, such as source-tree-20171205115433)

make status - diff -R source-tree source-tree-date | less (there'd be a little logic here, defaults to the most recent backup or give an argument to diff against a version

make tag - ln -s source-tree-date release1.0 (make a link to a particular version)

make revert - rm -r source-tree && cp -a source-tree-date source-tree

Answer 10

Well, after reading your question and lots of comments, I understood that you have the following constraints/scenario:

• 1 person per project;
• you simply can't use external tools other than Visual Studio 2005 for your project; you can't use GIT or any other SCM;
• while working locally, you can't let the project in some broken state, because you have automatic backups from time to time, and you need to make it work all the time;
• you need some history in order to track changes;

If you can't use Visual Source Safe (which has plugin to work with VS 2005), then you could use another approach.

Based on the above items, I suggest you organize your project folders such as below:

trunk           //last functional version of the app. IMPORTANT: YOU DON'T WORK WITH THIS FOLDER
    UnitTests   //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln
temp              //your working folder; has structure similar to trunk; changes will be commited to trunk;
    UnitTests     //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln  
build
    .history    //folder to contain changes in files and your comment (like commits in git)
    build.bat   //calls MSBuild to build temp\YourProject.sln, and run all unit tests
    save_on_trunk.bat   //if build is working, saves info from "diff.bat" in folder within ".history" with timestamp, and also overrides "trunk" with content from "temp"
    diff.bat         //compares files from "temp" and "trunk", using "dir" and "fc" commands
    history.bat  //outputs content from .history folder (contains file changes and comments)

Basic rules to follow here:

• your code control will be performed within the project's folder;
• you don't ever work in "trunk";
• you work in "temp", implement unit tests, call build.bat, and then save_on_trunk.bat;
• IMPORTANT: implement unit tests that run in total isolation; you need this in order to guarantee that new code won't break the trunk;
• since you have automatic backups, the chances of losing code will be smaller; therefore, you only need to make the "trunk" code to be in a working state all the time.

Answer 11

You have ran out of technical solutions. Only political solutions remain.

1) Unionize the developers. If there is already a union, challenge their position as not fairly representing the class of employee that is a developer. If forming a union of developer fails to gain support of half the developers, GO. You are a bad fit.

2) Newspaper ad. If your government doesn't guarantee free speech as a recognized matter of law, this will get you fired.

Answer 12

Just run git over a bare directory, with no server involved at all. It does not matter at all that nobody else uses version control, because you can version control your directory. Git was designed for exactly this rogue SCM introduction scenario, and it works well.

You will become a hero when the second person starts using it, even if you have to wait for some dinosaur to kick the bucket for it to spread. It's incompetence to manage large code bases without SCM now. It's like running a business without auditing anything, actually.

Answer 13

Git for Windows has a "portable" version. You can copy this to your PC, or keep it on a memory stick, without needing to actually install anything. If the problem is simply installation, this would be a workaround.

Do note that if they are flatly opposed to SCM, you may want to ask pointed questions about ISO-9001, DO-178B or other relevant software development standards.

Answer 14

There are actually three separate things that you would want to insist on as a professional developer: Code reviews, version history, and tracking change requests.

You can yourself track change requests. Not as nice as with the right tools, but you can. The second part is code reviews. For that, you need the previous copy of your code, and a diff tool. When you think a change is ready, you review it yourself by comparing carefully with the previous version, then replace the previous version with a new one.

For version control, if your workplace doesn't allow any decent solution, it's a box of writable DVDs that you need. Every time you have a version that you want to keep to be able to come back to, you create a new DVD.

(Obviously all of this is not advice that should be taken unless you are in a really bad workplace like the OP apparently is).