I remember being a small boy looking up at the night sky in a state of awe. Awe at what I was looking at knowing what I was actually seeing. I was one of these geeky kids – quiet, thoughtful, sensitive, but above all curious. Whatever I saw I wanted to understand. I’m told by my father that as an even younger child I used to cry when the wind blew in my hair – I like to think that I wasn’t a wuss, I just didn’t understand what the wind was and didn’t like it. (I’m sticking to that excuse!).

When I looked at the night sky and saw twinkling stars I wanted to understand what they were. So I read books and learned that what I was looking at wasn’t the sky as it was, I was looking at history. The stars were so distant that the light from them could take millions of years to reach my eyes and I wondered what they looked like now – were they still there? Was somebody looking back at me? That’s when I started to understand the scale of the universe out there. Cycling to the next village seemed like a long way, yet I knew that the planet we were on was a tiny dot compared to the star we’re spinning around, which itself was pretty small as stars go and there I was looking at countless stars in the sky just like our sun impossibly far apart.

But my eyes were really opened when I looked up at the stars in a remote part of Scotland with no villages or towns nearby – so no light pollution – and for the first time in my life I could actually see the Milky Way. Far from being a chocolate bar, it’s actually a side-on view of the galaxy we’re a part of and there are so many stars in them you couldn’t count them (I couldn’t count up to a billion back then). The feeling of wonder I had just standing staring out into infinity is the sort of thing you can only experience as a child. I was open minded, full of imagination, wondering what the view was like from these far flung places and wishing I could travel between the stars exploring in a vaguely Star Trek way (but without the skin-tight uniforms). Realising the distances were so enormous I started to wonder how I might get there within my lifetime.

Being a child I could think without boundaries or limitations and this led me to wonder about the nature of space, time and gravity (I did say I was a geeky child). I remember explaining to my parents how I reckoned that if you could create enough gravity between two points you could travel from one to the other without going through the space in between and they had no idea what I was on about (many years later my mother watched a programme about just such a theory and thought I was a bit less crazy from then on). Staring at the night sky captured my imagination and I could stare for hours at pictures of galaxies and nebulae wondering at the vastness of the universe and how I was stuck on planet earth staring at it through a telescope rather than being out there experiencing it.

I’ve never lost that sense of wonder about the universe and whenever I see photos or video from space looking back at earth I always feel almost emotional to look at where we are. I’m of the opinion that if everybody could go into space just once and look down on our planet as the blue marble that it is – so fragile with a tiny, wafer-thin band of atmosphere that makes our life possible – then the world would be a better place for it. Maybe in that case the first world would stop exploiting and plundering the third world for resources and enable our civilisation to last long enough that we can get out and explore the incredible universe we inhabit rather than destroy the beautiful planet on which we live. As I grew from childhood into adulthood I could see that people’s perspectives change. Instead of looking out into the world and beyond with a sense of wonderment and awe people shuffle along looking at their feet, eyes and minds closed, sleepwalking their lives away. Maybe it’s human nature.

But I’ll always be that kid staring up at the night sky with my mouth wide open imagining what civilisations have risen and fallen in the time taken for the light to travel from the stars to my eyes. How tiny and insignificant we are, how short our lives are in the grand scheme of things and what a miracle it is that I’m standing here staring at all. And fortunately I’m not the only one who thinks that way.

I’ve been a long time user of FogCreek’s bug tracking / project management / customer support / jack of all trades / master of all system FogBugz for many years. I use it at work (where it sits in the centre of our development process, we all revolve around it) but more importantly (ahem) for my own projects such as John’s Background Switcher it’s indispensable – without it I’d be lost. It handles all my support emails, defect and feature tracking, it’s my documentation repository, I use it to create release notes and when I’m doing beta testing of JBS I use its discussion forum functionality. There’s nothing better on the market and it takes away all the pain associated with managing and developing software so I can concentrate on what I’m actually building.

I’ve also used SourceGear Vault for version control for a few years and it has the handy ability to hook into FogBugz such that when checking in some code I can associate it with a case in FogBugz. This means I can look at all the code changes for a given case and see what it was that made me break some vital piece of functionality, although there’s no automatic way to see cases related to a checkin.

My good friend John Topley has been telling me how great distributed version control systems (DVCS) are for ages now (regular readers will know that John is forever telling me how great something is and then 6-12 months later I realise that he’s always right and follow up – like buying a Mac, an iPhone and many other things). When I attended the Scotland on Rails conference last year with John I saw a demonstration of working with Git (one of the DVCS out there) and I was impressed.

Very briefly, instead of having a central repository that you get the latest copy of the source from, make changes then commit them, you clone the entire repository (with all of its history) onto your machine. You can make changes, commit them (locally) and then when you’re ready push all those changes up to your central repository. You can also choose when to pull changes from the central repository locally – the cool thing being that you don’t actually have to update your local source with those changes until you’re ready. This means super fast checkins (since you’re not going over the network) and you can work in isolation while being able to unwind changes without affecting other people. When you’re ready you push those changes out so that everybody else can pull them to their local repositories. Suddenly things like branching, merging, multiple development paths and a host of things that can be painful to do in systems like SVN are much easier. If you really want to know about distributed version control systems then read Joel Spolsky’s tutorial here – hginit.com. What, you’ve read it already? Let’s carry on.

So a while ago I heard that FogCreek were working on a version control system – called Kiln – that integrated seamlessly with FogBugz but I was a bit busy at the time so added it to my “to get back to” list. A couple of weeks ago I finally remembered to have a look at it and bought myself a license (knowing that I had nothing to lose with their no hassle money back guarantee). After installing I started importing the source from my projects into Kiln. The first problem I had was that Vault seems to have no easy way to export the source history but since I’ve still got Vault running I can always go back and find older versions if I need to (which I most likely won’t).

The import was easy and it then became a case of getting used to using Mercurial (which is the DVCS system upon which Kiln is built) and how it does things. Having read Joel’s tutorial again (and paying attention this time) I was quickly up and running. Even though I’m the only person who works on my own projects (by choice), being able to have multiple cloned local repositories means I can try radical things out, take advantage of source control while I do that and choose to push the changes into Kiln or just delete the lot. And I don’t need to mess around creating branches only to later delete them or go through the pain of merging them in. Ultimately it means the time between checking in can be a lot shorter knowing that only when I’m finished with a piece of work do I need to push it to Kiln. In a team environment this rocks – you don’t have to worry about colleagues picking up your half-finished work and them complaining when things have broken.

When you’re developing on Windows you can install the “Kiln Client Tools” which puts TortoiseHg and some addons onto your system and makes authenticating and cloning repositories from Kiln dead easy. If you’re on a Mac you can install Mercurial tools yourself and it all works nice and smoothly. Since there are plugins for most development environments (like Visual Studio and Eclipse) you can use Kiln (Mercurial) seamlessly as though you were using SVN with the added security of it being a DVCS. Welcome to 21st century software development. Sweet.

The FogBugz integration with Kiln gives what I like to call “360 degree traceability” (something my friend Ian and I love about Team Foundation Server). If I commit a change with something like “Case 123: Fixed the divide by zero error” as the checkin note and push that to Kiln, then automatically case 123 will show that commit on its case page so I can see the changeset details and likewise when looking at the history in Kiln there’ll be a link from that changeset to case 123 in FogBugz. When trying to find out why changes have broken other parts of a system this sort of visibility can be incredibly useful, particularly where a team of multiple developers work on the same code base.

Another cool feature of Kiln which is absolutely no use to me on my own projects is a powerful code review tool. I’ve never really done code reviews in any place I’ve worked – it’s seemed like there’s never enough time to do it. However looking at how easy it is to create and manage code reviews in Kiln makes me think that were I using Kiln at work in my team then we’d definitely start using them. You’d pathalogically avoid branching and merging in Visual SourceSafe because it’s horribly hard to do (since SourceSafe sucks) but using a system like Mercurial makes that so easy you don’t even think twice about it. And so it is with code reviews, they’re so easy to do in Kiln that there’s no excuse not to do them.

In summary I’m very impressed with FogCreek Kiln. FogBugz has set a very high bar in terms of quality and ease of use and Kiln sits as though it was there from the start. Next time I build a development team and choose the tools I’ll be going down the FogBugz / Kiln route for sure, I’d be an idiot not to!