Branching: Friend or Foe?

Consider the following diagram, which is attempting to show features being added to program in a source control system.

BranchesFirst feature B is added to the mainline A, as feature B is a fairly large change and leaves the programmer with two choices (explanation of terms)

  1. They can add B to the mainline to create AB, this is nothing special and I’m not going to write any more about it.
  2. They can branch the mainline and add B to the branch (C) which then contains AB.

At first glance nothing earth shaking has taken place as adding B to the mainline or to the branch would produce the same thing: AB (I’ve labeled the branch C version to prevent confusion).  If the branch C is then immediately merged (integrated) back into the mainline to create AB in the mainline, then this is quite a sound way to add a major feature that require lots of changes to the mainline.

However things can rapidly become more complicated when branching if additional independent changes are made to either the mainline or the branch.  Consider what would happen if feature D is added to the branch to produce CD (ABD) and feature E is added to the mainline to produce ABE. Integrating the branch back into the mainline (to produce ABED) just became very much harder: especially if either or both of the new features changed a lot of files, as this increases the chances of changes occurring in the same file to the same piece of code in changes D and E.  This integration task would also become much harder and more time consuming if the branch had not been integrated back into the mainline after B was added.

Branching is not bad, it is a powerful and effective tool but it does require discpline to integrate often and the time investment to frequently perform the nessessary integrations to keep the branch(s) syncronised with the mainline.  The main risk with branching is that frequent integrations will not be performed and at some point integration will become practically impossible: as the branch and mainline will have so many independent changes that attempting to merge them back together could only be achieved with a truly hurculian effort and a corresponding collossal investment of time.

Remove features, don’t add them!

There seems to be something about programming that makes software engineers seek the perfect solution to a given problem or design brief.

Something that drives them to keep adding things to their program or library until they kill it with love for example Microsoft Word has a gazillion features but until recently (its has improved a bit) the GUI which is the main component of the program the user uses was horrendous to use and you could not locate most of those extra features easily.  This death by love seems to manifest especially consistently during framework, library and API development.  There seems to be a burning desire in every software engineer to make every library so generic it can solve any problems, not just what it’s design specification demands.

It is very rare to hear of a program, library or framework being criticised for doing too little or being too simple.  Usually the criticism is about the program or library being too bloated, too stuff full of features and love to be easy to use.  This criticism is so common and yet every day bloated libraries and applications are released.   It is rare and pleasant thing to discover a small concise application, library or framework that solves its problem domain excellently and no more.   In fact I can only think of a few examples:

  • SQLite is a C library which implements a compact, fast and efficient SQL engine, take a look at the list of companies using it, as well as all the open source wrappers available for it in most major modern programming languages.  This library is a study in minimalism, it does only what is required to meet its design goal with no surplus frills or bling.
  • DropBox is an online service with client applications (for PC and Mac) that provides file storage and synchronisation across multiple computers and operating systems in a refreshingly simple and efficient manner.  I was stunned to see how easy to install it was and how few configurations options are provided (hint: few are required by the client as it works out what it needs).
  • Google‘s search engine really needs no introduction.  Take a moment to look at the Google homepage and compare it with Yahoo!‘s or MSN‘s homepage: Google’s hompage is a study in simplicity compared to Yahoo!’s or MSN’s homepages.

I think I can best explain this by a talking about model making: as a young lad I used to spend hours building and customising Games Workshop miniatures which I used to collect and play war games with.  I got to the point in my teens were I was pretty good at the building, customising and painting of miniatures and won a few awards in local model competitions.  I can’t remember when it happened but I remember coming to the realisation one day that there is such a thing as too much customisation, building or painting and that it is very hard to know when to stop without first ruining a few models.  Later on I remember thinking about this concept some more and realising that this is applicable during just about any creative design work e.g. painting, gardening, music, programming etc.  Think about what would have happened if Leonardo da Vinci had kept adding brushstrokes to the Mona Lisa, would we still know who he was?

The key I believe is not to think ‘what can I add’ but to think ‘what can I reduce (simplify), refactor or remove’ from my design while still meeting my design brief/requirements.  As many compact, efficient libraries with concise, simple APIs can be combined in many more flexible and powerful ways than a few monolithic ‘kitchen sink‘ libraries with massively complex APIs.

In a nutshell: figure out your solution, then refactor and simplify it down until you meet your requirements in the simplest possible manner.

Friday Linkage

Here are the web pages that I have found most interesting this week:

  • Ten Killer WordPress Hacks
    I was surprised to find that this article was interesting enough that I intend to experiment with implementing some of the suggestions.  This is unusual as I usually find lists of essential addons or plugins or hacks for WordPress uninspiring to say the least.
  • Fruitful Time
    This is a personal productivity profiler, which also has a fairly rich feature set although unfortunately is PC only.   I especially like the fact it can show you the sites you spent the most time looking at as well as the programs and files.  I am both interested and a little scared of the potential findings of this tool, although I think curiosity is going to win out in the end!
  • Drop Box
    Personal remote storage would seem to come of age with this service: its multi-platform, free, has slick syncing and recover features.  Rands also likes it, which is enough for me to try it out.  I intend to try this for syncing personal files between work and home and also between Vista and MacOS on my iMac at home.
  • Learn Objective C
    I’m thinking about doing some Mac development, so learning objective C and Cocoa would seem to be required to achieve this.  This Objective C tutorial looks fairly decent: both in terms of content and presentation.
  • World Of Warcraft – Patch notes 3.08
    I’ve started dabbling with World of Warcraft again and after two years I find my self rolling a druid again (I used to play one in the UK), mostly to PvP with mates.  New patch notes means it is time for more entertaining theorycrafting, on which classes are being buffed (improved) or nerfed (diminished).

What web pages have you found most interesting this week?

Exceptions: Don’t bite off more than you can chew!

Many modern programming languages feature some form of exception handling facility, and although I am going to be talking particularly about C# in this post, it can probably be applied to any language that has exception handling.  Exception handling is very useful for the graceful handling of unexpected errors (exceptions) during program execution, however there are a few gotchas to be aware of when using exception handling.

Possibly one of the most important practices in the effective use of exceptions is to only catch the exceptions you are expecting and that you can handle safely, however a very common mistake when starting to use exceptions is to catch (and possibly suppress) every exception. For example:

try
{
// some code that throws exceptions occasionally
}catch{}

In the above example the programmer has discovered that their initial code is occasionally throwing exceptions, so they have enclosed the offending block of code in a try/catch block.  The use of a try/catch block means that any exceptions that occur inside the try clause are caught by the catch clause, this prevents the program from crashing due to unhanded exceptions.  However, the use of an empty catch clause means that any exception that is thrown will be caught by the catch clause.  The drawback to this is that the catch clause is empty, which means that every exception caught effectively disappears, which makes debugging and diagnosing abnormal program behavior incredibly hard, as that empty catch clause is effectively an exception black hole destroying any evidence.  This form of ‘exception handling’ is worse in my opinion than no exception handling: though it may prevent the program crashing due to unhandled exceptions it makes debugging the program exceptionally hard. The following snippet is an improvement:

try
{
// some code that throws exceptions occasionally
}
catch( Exception e )
{
// some exception handling
}

The above snippet is a distinct improvement on the previous snippet as the catch clause now catches exceptions and attempts to perform some form of exception recovery or logging. This is a lot better as at least some form of corrective action is taking place.  Yet there is still a drawback: the catch clause is still catching every exception that is thrown by the try block. This means that even the abnormal exception types the programmer does not expect are being caught.  The following is a better snippet:

try
{
// some code that throws exceptions occasionally
}
catch( System.ArgumentException e )
{
// some specific exception handling
}

In this example the programmer is now only catching the exceptions they expect their code to throw, which means that unexpected and abnormal exceptions are not caught. This is an improvement, as these unexpected exceptions will now filter up the call stack to more appropriate exception handlers and eventually to the try/catch clause in the main function of the application.  This means that when something truly rare and weird happens, e.g. an underlying system breaks causing an unexpected exception, that the truly exceptional exception is not caught by the original try/catch block but filters up to higher level exception handlers which hopefully alert the user (or at least the investigating programmer) that a truly exceptional event has occurred.

try
{
// some code that throws exceptions occasionally
}
catch( System.ArgumentException e )
{
// some specific exception handling
}
catch( Exception e )
{
// generic exception handling
}

In this last example specific exceptions are caught by the first catch clause which catches only the exceptions the programmer is expecting and then a second catch clause catches all the other exceptions the programmer did not expect. This form of exception handling is good if there is no general exception handler further up the call stack to catch the unexpected exceptions e.g. in a library. In summary exception handling is a very useful tool but you need todevelop the habit of catching exceptions responsibly and to not catch exceptions you don’t intend to handle.

New: Year, Resolution, Home & URL

Happy New Year folks!

Welcome to 2009!

A New Year’s Resolution

This year I aim to post at least three times a week which should mean at least 52 x 3 = 156 posts by the end of 2009.

A New Home for Me

Apologies for the lack of posts in the last few weeks, this was due to a combination of the Christmas holidays plus moving house and then having snow for the next ten days preventing us from finishing the move!  Thankfully the move is complete, although the unpacking is not (yet) but we are more or less settled into our new apartment and more importantly we are completely out of the old place.

A New URL for My Blog

You may have noticed that this blog has a new URL now, I decided to ditch the old splash screen and move the blog from blog.endlesslycurious.com to www.endlesslycurious.com.  This was mostly due Google Analytics recommendation, apparently the old splash screen was causing a large number of would be readers to give up, I thought the link in the Word cloud was obivious but I guess not that obvious.  I think I’ve managed to update everything that needed updated so all the links, images and RSS feeds should be working.