The business risk of not using version control for your custom software
Imagine having to use a computer that didn’t have an undo function. Where you could never revert to a previous version of a sentence, a paragraph, or an entire article. That would be awful, right?
This situation would be even worse for software developers. Not being able to return to a previous version of a codebase would be expensive, time-consuming, and at times catastrophic. Because of this, software developers have created something called version control which is like undo on steroids. But not all developers use version control. Do yours?
What is version control and why should I care?
A Version Control System (VCS), at its heart, is a way of tracking changes to a codebase over time. Each time changes are made, what changed gets recorded so it can be reviewed later. It’s similar to the change tracking function in word-processors where you can see what’s been added or removed. The big difference is the comment (or commit as it’s called) that accompanies the changes made. If your developers are good, it records why the change was made.
Having a VCS is is an essential practice of a maintainable system. It provides a complete history of what changed, and why it changed. Without it, you are at a significant disadvantage, and it could be costing you a lot of time and money.
Developers who don’t use a VCS are wasting hours, or even days or weeks.
When a VCS contains useful information about why the change was made, you have a significant head-start identifying and fixing bugs. Good commits save much time understanding existing code and assists in tracking down bugs.
Often, a developer might look at a piece of code and think it’s too complicated, or believe there’s a better way to express it. They will rewrite it to be simpler and make the code better. A noble pursuit, but it’s all too easy to remove an essential bug fix. The context that a VCS provides drastically mitigates this risk.
Without a VCS, you’re left with trial and error and hope.
Reduce your risks
A version-controlled codebase is a vital step towards deploying your software in a reliable, repeatable manner. The advantages of this are many:
- Knowledge of how to do it is codified. You don’t want essential information siloed in the head of an individual who could disappear.
- Risk of mistakes is reduced because there’s no human involvement. No more forgetting to copy an essential file which brings down the whole application.
- With deployment this quick and easy, it enables faster development cycles. The faster new features can be deployed into production, the sooner you see returns. Optionally, (depending on your risk appetite) more [controlled] experimentation for even faster returns is possible.
- Rolling back to a previous version of the application is trivial. If a show-stopping bug gets discovered, restoring the previous version is easy. The VCS also makes it easy to see the code that changed which must cause the bug, so it’s faster to fix.
We have enshrined many of these points in our company’s shared values. They are a crucial component to providing effective support and developing robust, reliable applications. They are a pre-requisite for us to work with a client.
Who owns it?
Great, your developers do use version control. Now, the next question is, do you, the client, own that metadata along with the source code itself? As far as we’re concerned, unequivocally yes. It’s work product created in the course of the development of your system. It is an essential artefact which provides a lot of benefits to you and any developer you ask to work on your system. Without it, you’re not getting everything you paid for.
If you’d like some help or guidance please get in touch for a no-obligation, free 15-minute call.