How to make sure you get the code from your software consultant

Are you afraid of hiring a software consultant?

Hiring a software consultant to create code is a great way to get access to knowledge and experience you don't have.

But one fear that can appear is the fear of never getting the code from them.

This fear is valid and it's good that you're thinking about it. It could happen, but it's very unlikely to happen if you take a few simple steps.

Use Version Control

With modern application development a system called "version control" is used to store the code and keep track of it all. A version that is now commonly used is called a distributed version control system.

Buzzwords-aside, this means that whenever someone is working on an application, they have the complete and entire history of the code.

In effect, every developer, designer, and anyone using the code on your team has a copy of the code for their use.

That means if everyone stays up to date with it, there will be multiple people with a copy of your software consultant's code. So you might not even need to ask them for it.

If a software consultant doesn't want to give you the code because it's not done yet, you can ask for a copy of their version control repository. This will at the very least have what they've been working on, complete or incomplete.

Own the version control system

An even better way to address this is to designate a specific version control repository as the "main". While it's exactly the same as everyone else's, it has a special purpose for your process.

It's where everyone puts their finished code. It's the official place.

By doing this, you can be sure everyone on your team will be putting their work here.

This central repository is especially useful when you or your organization is the owner of that repository. By having account ownership you'll be able to better enforce your process and make sure all of the code ends up here.

Github is a popular choice for this central repository but there are many other services you can use too. It's also pretty simple to set this up on your own.

Create a code publishing process

That's what a lot of this boils down to. Process.

Software development thrives on process. Heck, people themselves thrive on process.

That doesn't mean you have to have a highly structured and organized process, just that there is something for people to grab onto and know what to do.

In this case, there are a few processes you can use to make sure you're always getting the code from a software consultant (and everyone else on the team).

Require all work to be sent to the official repository when it's complete, like described above.

All incomplete work is sent to the official repository but in a different area (called a branch) or it's saved to another repository that other people can access (called a working repository).

At a minimum you can have your consultant send you a copy of the code at the end of each day. This might become unmanageable after awhile but it's a nice safety net if nothing else works.

My own policy is to update that central repository whenever a feature is done and also at the end of the day. That means worst case, only a single a day's work can be lost.

Getting the code from your consultant shouldn't be difficult, but some bad consultants make it hard. They think holding your code hostage is the best way to protect their interests.

Safety and collaboration are more important than that.