In this article we are going to discuss ten different qualities, or virtues, one needs in an SCM system. These ten virtues represent a standard, a "measuring stick", by which one can judge not just OurayCM, but any SCM tool. It is not all that is required for finding the right tool, but it is a very good starting point since it embodies the fundamental SCM needs of any software development project.
The first question that we need to address before presenting the standard is: How do we know this is the right standard? That is, by what standard do we judge this SCM standard? A businessman will point toward the right answer with the question: How does it affect my bottom line, my profitability? This is a good reply, but we can get more specific since what we are talking about is a tool for helping engineers do work. The thing that makes engineers profitable is their ability to produce, i.e., their productivity. If these virtues can enhance productivity, then they are good.
There is no simple prescription one can follow to achieve productivity on a software project. Rather, productivity is a complex, multi-faceted quality of an organization, having many requirements, such as:
Productivity on software projects is influenced by a wide variety of factors, and clearly, no single tool or practice is going to be able to solve all of your problems. However, it is also true that a single wrong tool or practice can kill productivity. So productivity on a software project requires a continual commitment to monitor, analyze, evaluate, and correct productivity issues.
It is unlikely that a given project is missing an important factor entirely. For example, you cannot execute a project without some degree of skilled people or without at least a marginally good working environment. So when trying to maximize productivity, we don't usually add in missing factors, but rather we improve the degree to which a given factor contributes to productivity. This idea comes into play when analyzing whether a given SCM tool will improve productivity: The main concern is not whether it supports SCM but to what degree it supports good SCM.
We can define SCM as the actions taken by developers in order to manage source code changes on a software project. However, it is more important to realize why we would even think to define such an area in software development in the first place. Why is SCM a discipline at all?
Anyone who has written software has encountered the situation where they wanted to see what the state of their program was 5 minutes, 5 hours, or 5 days ago. Also, anyone who has attempted to write software with someone else has seen the need to be able to share changes and reconcile conflicting changes. Almost anyone who has been releasing software to multiple customers has seen the need to be able to resume development based on some old release in order to fix a bug. These examples, and more, demonstrate the need for SCM and for automation supporting these SCM activities.
Although automated tools do not by themselves constitute good SCM, they can be judged in accordance to how well they support the virtues of a good SCM approach. A tool that makes it easier to achieve fidelity to the virtues saves time and thereby improves productivity.
We are going to discuss ten different but related virtues of a good SCM process. The common denominator here is that 1) each virtue is actually important to productivity in almost all SCM contexts; and 2) it is potentially furthered by automated tools. (There is nothing magical about the fact that there happen to be ten; we could perhaps think of more or pare down this list.)
Just as productivity is a multi-faceted project characteristic, good SCM is multi-faceted. Doing well on one facet isn't sufficient; we must do them all well or productivity is compromised. For instance, it doesn't matter if a tool is fast if it is hard to use and has poor sharing, history, and resumability features.
The core SCM virtues are:
Again, no SCM tool can make your SCM process have these virtues. But it can make it vastly easier to implement them. Also, you can see that these qualities interrelate, for example, usability depends to some extent on scalability; good history depends on integrity. A good system must do them all well; having a weakness in one is an Achilles heel that diminishes the overall productivity benefits of the whole system.
Integrity in SCM means that stored data correctly corresponds to the whole of what was intended to be stored. If a programmer has just tested the source in his workspace, found that it worked, and intends to record that state, the recording operation should be true to that purpose. No files should be left out nor should they be inadvertently mixed in with the changes that others have made.
SCM integrity is important to productivity for several reasons. Without it, version recovery is not possible: work can literally be lost. If only part of the changes you made to a given version are stored, then anyone who gets those changes can be subjected to a temporary but significant reduction in productivity.
SCM integrity depends not only on a properly working tool but also on good software development practices. A tool can record what you have done, but if what you have actually done misrepresents your intention, then integrity is violated. For example, if you add a feature and fail to test it before making the new code available to others, you will interfere with their productivity. No tool can force you to be careful, although it can provide the features to make it easier to prevent such occurrences or to help detect them when they occur (See Accountability and History below).
OurayCM helps you keep SCM integrity in several ways:
Sharing means that a group of programmers can all start from the same source, but then each edit their own versions of it in their own workspaces, and then share the changes each have made. It is the SCM basis of parallel development. It is also one of the principle virtues that initially drove the creation of automated SCM tools: without tool support, sharing can be achieved, but it is very tedious to implement manually.
Although the sharing concept is straightforward in principle, there are many variations on the ways in which SCM tools implement it, and there are diverse ways in which teams set up sharing patterns. In fact, the sharing implementation may be the single most complicated factor involved in analyzing and evaluating an SCM approach. For example, some tools use file locking as a key element in sharing, while in others file merging is used. Some tools support branching structures which can support a wide variety of sharing patterns across individuals and teams, and others do not support branching. Some support unstructured branching, and even branching of individual files and directories, while others support a more structured approach. These are all quite different and contradictory methods, and you must pick a particular approach.
What further complicates the issue is that the sharing approach you choose will greatly influence your development approach. If certain kinds of sharing are difficult in your tool of choice, then they won't tend to occur. E.g., if you choose a file locking approach, then refactoring code will be more costly and it will therefore happen less often. If the tool you choose supports branching but it is painful to use, then you will only use it when you absolutely must.
This influence of technology on development patterns can create confusion because past tool choice can lead some developers into thinking that software should be developed in a certain way which can lead them into thinking that the particular tool that caused that development mode is best. It can either be a vicious circle or a virtuous one.
Even though sharing can be a complicated aspect of SCM to analyze, it is important to do because getting it wrong can have serious productivity consequences. If you don't use an SCM tool, then you must manually implement sharing which costs you time and puts unnecessary restrictions on what you do. A file locking method for sharing can greatly hinder productivity by causing artificial development boundaries and all sorts of unnecessary developer interruptions and interactions. A tool that is overly flexible can create confusion over how to actually use the tool and lead to complex repository structures which are expensive to maintain.
OurayCM's workspace-centric model is largely what drives our approach to sharing. Our commitment to the other SCM virtues drives the rest. In particular:
For further details on OurayCM's sharing model, see the OurayCM User Manual, or The Basics -- An overview of OurayCM.
Independence in SCM means that you can choose when to share changes, that you are not forced into sharing changes just because you are taking advantage of all of the other capabilities of SCM (this relates to the scalability virtue). Independence does not mean isolation. On the contrary, isolation is trivial to achieve: all you do is work in completely different areas.
Independence is not simply a virtue that benefits individuals. On larger projects, one might have teams of teams, or even larger organizational structures, and each of these may want independence from the others.
This is an area where many SCM tools and environments quite notably fail. The reason for the failure is usually related to the tools: some tools make it so difficult to implement independence that it is simply not worth it.
One of OurayCM's principle design goals was to achieve independence; it works very easily, "out of the box". In OurayCM:
Accountability in SCM means that you can know who did what, and that what they did can be known.
Accountability is critical to any software project. It is not primarily about assigning blame or reprimanding. Rather, it has a twofold purpose: 1) To identify the source of the problem in order to gain insight into it. The person responsible for the problem is most likely to be able to fix it. 2) To provide feedback essential for correcting bad development habits. If someone is making errors but is unaware of them, they are likely to recur.
OurayCM fosters accountability through these basic features:
SCM history is the ability to identify what happened in the past.
In principle, the purposes for which history is needed are unlimited, but one is fundamental to software development and deserves pointing out.
The most common use of the history ability is to find out what went wrong. While programming is usually an activity oriented around the future (in that we are usually adding new features that have not existed before) sometimes when adding a new feature we break an old one, and the easiest way to identify why it broke is to be able to see 1) how it was in the past and/or 2) what changed relative to that past.
Some other reasons why history is important are covered in other virtues discussed in this article, such as accountability, resumability, and recoverability. Other virtues, which indirectly capitalize on history are sharing, independence, and scalability. And there are other uses of history that you can probably think of, uses that might be particular to your own project.
Relative to other SCM tools, OurayCM has an extreme fidelity to this virtue. In fact we know of no other tool with such high fidelity to history out of the box. The key to this is our core architecture of branches as sequential versions, our workspace-centric model, our Durable Versions, and properly implemented file and directory renames. The benefits you get with our architecture:
Recoverability in SCM means that you can reproduce past versions of your work.
Recoverability is important because developers may need to change a previous version, or they may need to identify when a bug was introduced, or they may need to start over based on how the software was a while back. Lack of recoverability is often not noticed until something unexpected happens, and then it is noticed along with a sense of panic and extended overtime.
Resumability is the ability to resume development from any past version of your source.
The most common reason why you need resumability is to provide bug fixes for released versions of your code. But resumability is a value on a finer-grained level than that (assuming it is easy enough to use). For example, an individual developer might need to restart development from where he was a few days prior (say, because of a reprioritzation of his tasks), and then later pick up from where he left off.
Many tools make resumability tedious or confusing. It is quite common for developers to completely avoid using the SCM tool for this feature, essentially making a copy on release and then modifying it outside of the SCM tool as desired, and manually tracking changes.
OurayCM's powerful branching model and Durable Versions allow you to resume development from any prior version and then transfer the new changes to any other branch. When you resume development from a particular version, you can branch on demand from that version; there is no need to plan for this ahead of time.
OurayCM resumability works exactly how you would expect it to work. Picking up from where you were at any point in the past is not a difficult concept to understand; it should not be a difficult thing to do in your SCM tool.
Performance refers to the computing resources required by the SCM system. Required resources relevant to SCM includes required hard-drive space, memory (RAM), CPU cycles, and network bandwidth. Excessive resource requirements can waste time and sometimes money.
Performance is a relative virtue. As memory, hard-drive, and CPU performance is constantly improved, what may have been unacceptable performance one year becomes fine the next. Further, some developers manage source code having hundreds of files; others might deal with thousands or even tens of thousands of files. Obviously, each may have a different opinion on what is "high performance".
OurayCM performance attributes:
Usability is the degree to which a given SCM system is easy to understand and use. Usability is important to productivity because a difficult to understand tool will take a long time to learn, and a tool with a complicated interface will require a lot of interaction and may be unreliable.
Tools can fail on this attribute for a number of different reasons. A tool that does not scale will create different usage patterns on different scales, complicating the usage. A tool that has irrelevant flexibility, which allows you to do things you'd never want to do, thereby has unnecessary complication. A tool that won't do things it ought to do, forcing you to work around it, causes increased complexity. Or tools that make you do manual bookkeeping (such as keeping track of merges) is unnecessarily complex. Finally, a tool with a weak and incoherent conceptual model will be more difficult to use than necessary: It is better to put a stake in the ground and have some people disagree than to try to be everything to everybody.
OurayCM was originally conceived out of frustration with usability problems in common SCM tools. The designers had previously written scripts for a number of well-known tools in order to make them simpler to deal with and in the end decided that the best solution would be to build a new tool.
There are only a handful of routinely-used OurayCM SCM operations, and they have clear and precise meanings. We recommend reading The Basics -- An overview of OurayCM to see the simplicity of OurayCM's conceptual model. The OurayCM User Manual has an example which demonstrates how this model might be used on a two-person project.
Scalability means that the SCM process and tools work in the small and the large. This means that as the number of developers, projects, files, or other SCM-related units grows, the SCM process and tools gracefully handle the growth rather than breaking down at some point and having to be replaced or supplemented at the larger scales.
For small projects, scalability is merely a potential productivity issue, but even a one-person project that must maintain multiple deployments has scalability needs. Effectively managing multiple versions requires good branching support, the cornerstone of scalability in SCM.
Larger projects have an inherent need for scalability. For example, having poor branching support will lead to workarounds, such as code freezes, which hinder productivity. Large projects are inherently made of many smaller projects (whether or not they are literally called "projects"), and having to switch SCM paradigms when moving from the individual to the team level results in unnecessary confusion and/or complexity (i.e., scalability is required for usability).
OurayCM is designed to work well for one programmer and scales to work for tens, hundreds, or more. OurayCM's branching is simple enough to be useful for a single programmer managing multiple releases but powerful enough to build an enterprise SCM system with.
(Watch this space for a discussion about our forthcoming Remote Repo Security/Filtering feature).
The above ten virtues embody a standard by which you can rank different tools. If you wanted to approach the ranking systematically, you could analyze each candidate tool in accordance to each virtue, ranking one above the other for that virtue. Choosing the best tool among good tools will still be a judgment call, but proceeding in this manner should make that judgment easier.
Another factor to consider is how well the tool meets your particular needs. The above virtues represent the needs of most developers in an abstract, essentialized form. However, there are other needs for features that are not generally essential but that may be essential for some developers. For example, OurayCM's ability to perform remote, network-disconnected SCM is not needed by developers who always have a reliable network, but it may be crucial to other developers who don't always have such a network.
Some care should be taken when deciding on these particular "must have" features, because if you are wrong about one of them, then you might end up compromising on the more fundamental virtues in order to get a relatively non-essential feature, which in the long run is going to cost you.
For example, IDE integration is a feature one might consider a "must have". However, most developers get the idea that they need the integration from working with particular SCM tools that would be a nightmare to use without it. I.e., a tool they had used in the past lacked good workspace management features, and they are incorrectly assuming that all other SCM tools will lack those features as well, which may or may not be the case. So the real "must have" here is that if a given SCM tool lacks good workspace management features, then it must have IDE integration to make up for the lack.
If you have any feedback on this article, feel free to email the author.