In this episode, I want to talk about Source Control. Source Control is a tool that should be available to your Software Development and at the heart of everything they do. The aim of this episode is to introduce to you what it is, why they should be using it and ultimately why your are probably spending money on it. This is part of a mini-series which takes us up to Christmas. I will introduce some of the tools and practices that allow for the fast delivery of software and ultimately delivery of value to our customer. We start with Source Control in this episode, then move through a number of closely related topics to getting our software investment in front of our customer as quickly as possible.
Or listen at:
Published: Wed, 20 Nov 2019 16:13:22 GMT
Transcript
Wikipedia defines Source Control as:
"[Source Control] is the management of changes to documents, computer programs, large web sites, and other collections of information. Changes are usually identified by a number or letter code, termed the "revision number", "revision level", or simply "revision". For example, an initial set of files is "revision 1". When the first change is made, the resulting set is "revision 2", and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged.
The need for a logical way to organize and control revisions has existed for almost as long as writing has existed, but revision control became much more important, and complicated when the era of computing began. The numbering of book editions and of specification revisions are examples that date back to the print-only era. Today, the most capable (as well as complex) revision control systems are those used in software development, where a team of people may concurrently make changes to the same files."
Before we go too much further, its worth briefly touching on what makes a software program.
As a simple summary, a software program is set of instructions for a computer to carry out some task.
Software Developers can produce those instructions in a variety of languages. These languages can differ greatly in the same way as spoken languages - different grammar, language rules, etc.
In addition, they can also differ greatly in intent. Some languages are better designed for certain types of problem or industry - much in the same way that very domain specific language can evolve within certain industries or business disciplines.
Regardless of the language used to write these instructions, they will be written and then stored as some form of text.
This text will be human readable; as often it is just as important for the next developer to understand the intent of the software program as it is for the computer on which it runs.
For the purposes of the upcoming episodes, I will refer to these written instructions as software code. Other terms that you may hear are computer code and source code - source code referring to it being the source of the software program.
It is for the effective collaboration on that software code that we need to provide our development teams with Source Control.
Let's think about this in terms of creating a legal contract or sales proposal.
If this is a document you are creating on your own, you may open Microsoft Word, make an initial draft and then save to your local documents.
As you work to complete and refine that document, you will likely version it in some manner.
For example, you may include a version number or date in the filename when you save it ... So for example,
- Proposal-v1.doc
- Proposal-v2.doc
- Proposal-v3.doc
- Etc
Or you may rely on the automatic versioning features available within Microsoft Word.
Either way, you will likely find benefit in being able to see the changes you make to a document over time - especially if you need others to review it.
Say for example, you need a business partner to review, or a legal team, or maybe even your customer ...
Being able to see those version differences is exceptionally valuable by allowing focus on those parts that have changed - likely saving the need to re-read the entire document each time and trying to remember what has changed.
If you've ever used the change tracking feature in Microsoft Word, you will be familiar with the benefits that this gives reviewers when a document is changed repeatedly.
In addition to the ease of being able to see the change, the feature also provides a means to comment on the document along with being able to Accept or Reject those changes.
This can help greatly in arriving at a shared understanding of what the final document should look like.
Now consider when you have multiple people working on that document at the same time.
Maybe the legal document or sales proposal is of such complexity that it requires input from multiple people in your organisation.
You could pass the document from person to person, with each adding their part to the sum of the prior work. But this can quickly become inefficient with those at the end of the chain potentially providing input weeks or even months later. And those at the beginning of the chain can become divorced from the document due to downstream changes - potentially nullifying or contradicting their input.
I've certainly been on the receiving end of documents that have been generated in the fashion. It can be quite obvious that document has been built this way due to the jarring impact between different sections.
To solve this, you want everyone to be collaborating on the same document, at the same time.
By having a shared document, it means that mistakes and inconsistencies can be spotted early.
For example, if the sales team is making a claim about a service you provide, then the legal team can highlight any impact of such a claim.
Most peoples first exposure to such a shared document is something like a Google Docs - where the document is actually edited in the web browser allowing real time collaboration.
In it, you can see as people are making changes - along with adding comments and reviewing changes.
The same features are also available in the Microsoft Office 365 and other common tools.
These are becoming standard tools in effective collaboration.
And the same is true for Software Development.
Software Developers need a way of collaborative working which allows for sharing of software changes, ability to review and comment on those changes and means of revisiting the history of those changes over time.
And this is what source control provides.
The source control should be the definitive source of any software code.
It is where all the developed code should live - it should be considered as valuable as any other asset that your business relies on. You should consider its loss a major impact to your business.
The only thing that wont be on there is any changes that the development team are currently working on - and this should be kept as minimal as possible (ideally no more that a few hours of work).
As with all things, there are variants of source control - most all provide you with that centralised storage for collaboration and a history of changes - who did what and when.
This creates an exceptionally strong audit trail - generally providing history of changes since the inception of the project.
Some of the more popular ones will even allow developers to work disconnect (on a plane for example) then later merge any changes back in. All the while still retaining a history of those changes.
This functionality is pivotal to providing a team a method of working on a software product without constantly corrupting each others work.
So hopefully you get an idea of how important source control is if you are relying on the resulting software product.
Source Control systems, certainly the better ones, do cost money.
And I would personally recommend the cost for a professionally hosted service rather than trying to run a free version in house.
Most teams could be performing more valuable work than spending time keeping it running.
Remember again, this is important stuff. Its resilience and security should as much as considered as your financial records. In many organisations, that software code represents thousands of developer hours of creation - and likely to almost impossible to recreate accurately.
In this episode, I introduced Source Control.
The means by which a team can collaborate effectively in the building of a software product while retaining a history of who changed what, when and why.
I equated Source Control to familiar collaborative tools found in business tools like Google Docs and Microsoft Word.
And I finished by stressing that importance of that software code stored in that Source Control.