These days about every adept in software engineering knows what version control (VC) is: A tool to commit changes into remote repositories. It is seen as replacement for some sort of postal system, where the source code is literally sent to a superior or customer.
But there are more aspects to know about it, which I am going to write a about taking Subversion (SVN) as an example. One of it is lowering the barrier of committing code and enabling to maintain flow. First we have to distinguish between centralized and decentral VC. I will limit this post to the first.
If you have ever seen developers working without VC you might probably know what mess it is, them copying working revisions to a dedicated directory, delving further into curring edge one and then eventually figuring out what they have to revert to from one of these folders – for minutes. A VC saves a good amount of time sparing the developer bookkeeping about the changes he made. Most importantly, without VC more than a few developers couldn’t work on a common code base without overwriting each one’s changes, synchronizing those history-folders and a good amount of coordination. With VC sharing changes (and reverting to a former changeset) becomes feasible.
Management or QA can see what was changed by whom, when and in which context. Thus they’re able to transparently track progress and account revision transitions to tickets, roadmaps and milestones without the often referring to the programmers.
In SVN this can even be automatically done by establishing hooks – scripts to be run on given actions, such as the ‘commit’.
Software engineering wouldn’t be that easy as it is with VC. Novice programmers are inclined to keep their throphies, working functions for example, and drag them from revision to revision in commented-out parts of source files. In most cases this happens due to lack of understanding VC fullfills archival purposes: At any given time it is possible to revert parts of the code to a former revision, and reading them is possible, too.
Indeed that archival aspect is important in staging, where staging is the intermediate process to deploying an experimental/development version of a product to production systems. Should something go wrong a revert to a well-known working revision can occur. Even more importantly, errors can be tracked down to the small subset of code which actually has changed since last version.
Given common code-base updating systems becomes trivial: A revision is agreed upon to be promoted to a version to be deployed. On a systems that version is now checked-out and any upgrade scripts run (which should be versioned, too). The aspects earlier described in mind, some even version-control configuration directories.
A central versioning system enables usage of tools such as continuous integration, style-check and so on. As soon as code gets committed hooks can be utilized to trigger a build, test or check.
And, such hooks can be used to run a check whether coding styles have been applied by the committor – if not, the code can get rejected from being written to the shared code-base as long as the novice does not correct the violations. Because this is done automatically, by a “machine”, no one from the team (or the QA) seems educational. Without losing face the coder can fix his mistake silently and preserve motivation.
When faced with the challenge to paint a blank page or in our case, append to existing code, one has to overcome a virtual barrier. This barrier is said to be the exact opposite of the state called flow, which to achieve is desired in the pursuit of efficiency. VC utilized right can lower that barrier down to flow significantly:
Being able to get back to a working revision creates the feeling of safety and control, eliminating the need for explicitely storing and reading obsolete code or switching to update tickets or roadmaps maintains focus. Every commit becomes a small reward and updating to changes of others visualizes parallel and organized working of the group. With continuous integration and automatic (dev/staging) deployment one’s effords seem to have immediate consequences – which help keeping up motivation and everything the flow of productive working.
Yet assigning tasks not too hard and not to trivial is still the complementary challenge of the team leader.
Tags: pursuit of efficiency, qKAI, software engineering, subversion