Title: Professionalism in Programming #7

As 'professional' programmers we have a duty to take responsibility for our work. This is to guarantee the quality, safety and maintainability of our code. In this column we are going to think not so much about the safety of our executables as that of our development processes.

Even though we are programmers we have the responsibility to ensure that our work is:

We will touch on these issues below. What we need to bear in mind is that we have a responsibility to ensure that these requirements are met, not necessarily to meet them entirely ourselves. Maybe these issues seem tediously removed from the act of writing code, but we should not belittle their importance.

So this is obvious is it not? We are all well aware that we are stupid if we do not make regular back ups of our work. But we are human; if we rely on doing it manually then we will just forget or leave it too late, or... I am frightened when I discover how much work gets done on computer systems and workstations that are not being backed up^[1]. The level of risk is preposterous.

Now, I am not advocating that the professional programmer should make a daily personal back up copy of their hard drive. Rather, that their responsibility lies in ensuring that important files are placed on a file system that is being backed up. In fact, it is often best that the responsibility for performing the backups rests with someone specific, usually the IT department of a company - it is more likely to get done. After all, it seems that most good programmers have little or no common sense, let alone memory.

There is not a great deal of difference between the requirements for personal or corporate backups. The only real difference is the scale. Back ups need to be:

For example, even when working on an un-backed up NT workstation I often save my work on an NFS-mounted Unix file server which is backed up rather than on the unsafe local disk.

There is a whole realm of technical detail involved with making back ups that we are not able to go into in depth in this article. For example, in multi-user environments when are the back ups made? (The answer is usually during the night when there is less computer activity and less information changing on the file systems being backed up). We should also note the differences between 'full' and 'incremental' back ups - the former being a complete physical copy of a filesystem, the latter a report of the differences between the filesystem now and how it looked at the last back up. There are various benefits and costs of each approach - a mixed approach is usually best.

The main point we should bear in mind is that our work is not safe if it is not retrievable in the event of human or mechanical failure. Is all your work backed up? If not then I urge you to remedy this now, even if it is 'only' for personal use.

It is one thing ensuring that your source code is obtainable in the event of failure. But how accessible is it - can other developers in your company use it? Perhaps you could work on a shared file server so others can see your source files too, maybe even work on them alongside you. But how ideal is this? How do you make sure two people are not working on the exact same file at the same time causing all sorts of confusion when they each hit the "save" button? A better way of managing the code is to use a source control tool.

So what is source control? Well, it is a method for one or many people to work on the same 'repository' of source code in a controlled manner. What is does 'controlled' mean? Let us think about some of the problems that can be faced if people were to work on the same repository of code (on a shared disk on a common file server, as in the example above).

There are a number of potential problems:

A source control system works around these kinds of problems. It allows each developer to 'check out' their own copy of the common source repository and work on that in isolation, whilst enabling them to keep up to date with all the changes that are being made by the other users - bringing their copy up to date as and when required. Any changes that have been made can be 'checked back in' to the main repository for all developers to see. The source control tool also allows us to control which users have access to which parts of the code base, the system administrator will have the privilege to set this up^[2].

Some systems do not allow two users to edit the same file at the same time (using a kind of locking mechanism), alleviating the problem (1) above. The more sophisticated systems allow users to edit the same files concurrently, the changes are merged back together as they are 'checked back in'.

The repository will contain important revision information that allows you to check out any version of each file. Therefore you can make changes in the knowledge that it can be fully backed out of. This is a very powerful weapon indeed. The repository is a log of all changes made means that you also get extra benefits:

The main repository can be held on a local machine (I tend to work like this for small pieces of personal work not destined for main company repository) or on a remote machine, accessed over a network connection. Indeed, good source control systems allow repositories to be accessed within a local network or by developers world-wide. In the latter case they can be very useful indeed, removing the burden of developers in different time zones needing to co-ordinate when they update files. (In fact, I have recently worked like this on a project with half of a development team in the UK and half in the US - and the UK developers split over two sites).

If you are using an important company repository it will be held on a server that is being backed up. This means that there is less of a reliance on personal workstation back ups - most of the work you have done is checked in, and the loss of your workstation will not be so critical to the project as a whole.

Most source control systems also serve as configuration management tools. Allowing you to generate multiple 'products' from single repositories of source code. They manage the configuration issues, i.e. which files are included in which product, which versions of these files, what sort of compilation environment^[4] is required, which documentation relates to which product variants, etc. Some configuration management systems also integrate bug tracking and work flow control in their system.

In some senses the term configuration management describes how a source control tool is used during the entire software development process. It is subtly different from pure 'source control', encompassing it and adding a development procedure to its use. However, some tools provide more configuration management capabilities than others.

Using configuration management we would store more than just source code and object code for which have no source (e.g. from external suppliers). We would include specifications for each part of the system (tied to packages by the system), test cases, test results, documentation and release notes, tracking information for hardware versions, plus entire build environments.

Finally, we should be thinking about what we do with the source code as we work on it. You can never fully account for human stupidity. 'Top secret' company work should not be left on a laptop in an unlocked car, for example. Likewise source code should not be left on a publicly accessible network.

An element of professionalism includes understanding the terms of any contract that you might be working under - and acting appropriately. Many employment contracts limit who you can discuss work related information with, and also assign rights to any work you produce to that company. Tied with this is the common use of non disclosure agreements (or NDAs), legally binding agreements which prevent information shared between companies from being leaked to parties outside the agreement.

Programmers should also be careful to ensure that their log-in passwords are known only by themselves, as should any computer system user. Outsiders (and even possibly malicious insiders) should not be able to sabotage work using inappropriate access rights.

We have discussed various methods of working that ensures we take responsibility for the source code we create to ensure that we do so in a safe and controlled manner.

I have not really spent too much time with any of the proprietary source control tools mentioned in this article. Perhaps readers who have would write a few words on their experiences with them for the Member's Experiences section of C Vu.