SCM

There is a book online by Eric Sink about source control. You would think this guy knew what he was talking about. He founded a company that produces source control software. I thought I would share some of the things I learned or recalled while reading his book.

The first order of business is defining source control. It is also called version control or SCM. This let’s developers work in parallel on the same code base. You must learn how to do this. You don’t get taught this at college. Some example of source control systems are SourceSafe, Subversion, CVS, and Perforce. The product created by the author Eric Sink is Vault.

Source code gets stored in a repository. You can get a copy of the code to view. You can also check out a copy of the code. The repository will automatically merge your changes in with changes from other developers. How is this repository maintained? It can store the whole copy of every version. However that is not very space efficient. Instead I believe most repositories only store the deltas between each version.

You normally have the ability to name a certain version of a file or your whole code base. This name is called the label. Another idea in source control is branching. This is where you have two or more copies of your code base at the same time. The good source control systems are integrated right into your IDE. I must confess that, even though my own source code tools integrate with my IDE, I do not use this functionality. I prefer to do things manually myself.

Complex Requirements

I recently checked out an article by Scott Ambler in Doctor Dobbs magazine. And I paid attention because his name sounded familiar from the past. I think he may have written about C++ in the past. From his bio, he is into process and agile methods. His article affirmed that requirements are complex, but applying Agile to them can help.

We do not want a heavy level of documentation for requirements. Take an example from Scrum. They have something called a backlog which prioritizes requirements. This is a good methodology to manage simple requirements.

You would think that complex requirements could be broken down. The problem is that if you do break down the requirements, the smaller pieces might not make sense by themselves without the context. You need to try to group the smaller sets of requirements in a smart fashion for this to work.

Just like traditional object oriented analysis and design, you should break the requirements into use cases and scenarios. The use cases should be simple. There should also be very little documentation.