Why I Picked Mercurial

I was a little dubious about the hype over distributed version control until I bought Jon Loeliger’s excellent “Version Control with Git” at EuroPython last year. I was sold – it made sense. I’d used both Git and Mercurial a little before reading the book, but more out of necessity than design to be able to checkout fresh code from a couple of different open source projects. Like many people, I didn’t “get” DVCS at first – how could it possibly work in practice??? (The answer is: very well, thank you)

Deciding your choice of distributed version control is as much down to personal preference as your choice of editor, programming language, or operating system. Git impressed me by its massive range of tools, good Subversion interaction, pragmatic approach and the fact it’s great to drop the word “Git” into polite conversation. I have a lot of respect for Linus Torvalds and his pragmatic approach to development, and his decision-making process in crafting Git to make kernel development easier. The problem was that with great power comes great responsibility and, more importantly, complexity.

For personal development, I drifted towards Mercurial because it seemed to fit my development process much more comfortably, and had a slightly more elegant feel. The learning transition from Subversion to Mercurial was small compared to the transition from Subversion to Git. However, Subversion repository interaction from Mercurial is not so mature. Go figure. Despite that, Mercurial makes a great replacement for Subversion, eliminating all the niggles and problems of the latter. It feels more lightweight than Git, yet packs all the power and flexibility I need for the kinds of projects I work on.

Mercurial is written in Python, which is useful but not an essential reason, and very extensible. It works well on multiple platforms, while Git seems to be fine on my home OS environments (OS X, Fedora) but less developed for Windows which I have to use at work. Mercurial Queues are a fantastic idea that I really wish I’d had access to on several occasions in the past – they would’ve saved me so much time and pain. History can’t be altered, like in Git, although I do think the feature has its uses – just that it can also have its abuses. Mercurial seems to handle renames in a more natural way to me. HTTP-based sharing in Mercurial is pretty good, and efficient too.

Don’t get me wrong. I think Git is a fantastic piece of version control technology, and GitHub rocks as a supportive environment, but Mercurial has the edge for me. It rocks, and development is improving it at a respectable pace.

If you haven’t already seen Joel Spolsky’s Mercurial tutorial that has been doing the rounds, you can find it at: http://hginit.com/ – it’s the best introduction I’ve seen so far.

If you haven’t switched to distributed version control, take a look at Mercurial or Git (or Bazaar, if that way inclined) because it really is a significant evolution over centralised systems like CVS and SVN.

Game Progress: 1

I’ve mentioned in a couple of previous posts about a wargame idea I’ve had swishing around my brain for a while now. The good news is that I finally made a start.

The main problem with getting started was, simply, getting started. No matter how many times I sat down to code, I ended up getting distracted or hitting coder’s block and staring at a blank source file in Aquamacs. Evenings aren’t my best time for programming, especially after a tiring day, which doesn’t help much. The other problem was that the overall task looked both large and hazy. A bit like most projects, except this time the customer is me and the deadline is “whenever”.

The game has three main aspects: historical and non-historical unit availability and deployment, unit combat and movement, political opinion and events. The first area was already the subject of an earlier prototype, of which the only thing I have retained are the unit availability data files, and seemed like a good starting point.

Given the coder’s block, I went back to basics and wrote out a series of bullet points on things needed for this part of the game. After struggling to get a couple of bullets down, things began to flow and I racked up quite a good list of functionality. Some of the ideas have been with me since the very first time I thought about writing this game (a couple of years ago!), while others were fresh. Although I reviewed the list to weed out any weak ideas, I ended up sticking with the list as-is – give or take a few tweaks of terminology to keep things consistent.

Now, the obvious starting point would’ve been to start writing some PyGame code straight away. Much as I’m a visual person, my lack of experience of PyGame encouraged me opt to hold back and take a different approach. My main worry was that I would bog myself down in PyGame, without really considering what I was going to achieve. Looking at my list of tasks, I started to model some of the data required and began to pick and implement some basic functionality using test-driven development. By isolating these models from any user presentation, and from writing any UI code before I had gained some ground learning PyGame, I found myself gaining a much better appreciation for what I was aiming to implement overall.

As I wrote little bits of functionality, I refined my existing task list and design until I reached the critical point: I needed to start on a UI. My first thought was that I should prompt the user for a screen resolution and so on, but then I realised I could hard-code it to my MacBook’s screen dimensions. There was a tinge of guilt, but it was the simplest option at the time to get something working and I’m the only customer so far, okay? After a few iterations of work, I now have a screen displaying three different lists (deployed units, units available for deployment, and units that are likely to become available soon). I can increment the game turn, each one representing a week of real time, and can watch units switch between the various views as time progresses and forces arrive and depart the theatre of operation.

As a game, it currently sucks: it’s not so much a game as a rolling chronology of the order of battle. But that’s okay because it’s barely a fraction of the final vision and the current process is geared at building a suitable foundation for the rest of the game. I’m not thinking “game” just yet, because most of the real gameplay happens in the other two aspects. The current UI itself is temporary, because the different lists will not be presented in their current format later on. The deployed units, for example, will be shown on a game map as NATO-style unit symbols, not a list.

The great thing about tackling little chunks is the motivational factor. Never has the term “low hanging fruit” been more apt – by searching the to do list for small tasks, I can fit coding into spare moments. The sense of progress by chipping away at the tasks is a great motivator. Periodically I refactor the code to keep things fresh, to remove code smells and ugliness that I feel guilty about, and generally improve the design based on my experience of the project so far.

Anyway, that’s my little reflection on the work so far as I’m too tired to write any Python tonight. After hitting some more internal milestones, I want to have a public milestone of some screenshots of the first game aspect. Since I’m the customer and don’t have a deadline, I can’t say when that will be… but hopefully in the next few weeks.

What “Being Agile” Means To Me

At university I was taught the principles of software engineering. The methodology we used was termed “the waterfall model”. Given I was a self-taught programmer until then, it sounded great – a structured, disciplined and “engineering”-like process that would turn me into a coding professional.

The trouble was, outside of the ivory towers of academia it just wouldn’t fit. I jokingly say to people that the process works great if you know exactly what you want at the beginning, everything works exactly to plan and you’re probably NASA. For everyone else, no project plan survives first contact.

I tried for some time to apply rigid software engineering principles in the hope the lack of success was down to inexperience and poor technical skills. Gradually I realised the problem wasn’t the methodology as such, it was that each step in the process wasn’t an exact science, nor did they follow a linear sequence. We can’t do a perfect design up front, because no customer knows exactly what they want. We can’t do exact time and cost estimations at the start, because no developer knows exactly how long it will take to build or even how it will be built. No wonder the poor project manager wonders why their Gantt chart goes stale so quickly, and the customer gets shipped a lemon six months or a year down the line.

There is only one time when everyone knows the whats, whens, whys and hows of a project with any certainty: when the project has finished. And given that many projects are, supposedly, shipped late and over budget that knowledge is often painfully gained. There’s a reason why some organisations call retrospectives “post-mortems”.

Wouldn’t it be great to have the benefit of hindsight for each and every project? Yes, it would. Better yet, we already do to an extent. For every project we work on, we gain knowledge and experience that we apply (one hopes) to future projects. Unfortunately, every project is different. Teams change, customers change, technologies change, budgets change, tasks change, deadlines change, risks change. Even redoing a known project from scratch, using exactly the same customer and team will result in something different. (If it doesn’t, you have a big problem).

Change is often seen as a bad thing, because people don’t normally like change. Go order a mass desk move to a team in mid-project and take copious notes on the response. Bonus points if the move is the day before a hard deadline.

For me, Agile is about managing change. Scratch that, it’s about embracing change.

When we start a project it’s fresh, new… and rather hazy. The customer has a vague idea of what they want, and the development team has a vague idea of what needs to be done. If you’re lucky, those two vague ideas are of the same hazy vision. As we progress through the project, our collective understanding of the domain improves, and the overall vision is refined. The customer slowly realises what they really want, and the developer slowly understands what the customer is aiming for. The developer’s estimates become more accurate, the design takes a more definite shape, the software yields more value to the customer. We all get better.

By embracing change, by acknowledging it’s going to happen, we work on ways to make change less painful. Changing something after a lot of time and effort is not fun, so short iterations of work mean more plentiful feedback and thus more regular course corrections. Short iterations of work mean concentrating on building only what we need for an iteration – we keep our design and our code supple, working on what we need to work on at a given time. We make our code simple and understandable, so changes are easy, and testable, so we can implement and refactor with confidence.

Agile at its very core is about embracing change. Change happens all the time, we can’t avoid it, so we need to take it into account when we develop software. No matter what Agile methodology you use, or want to use, XP, Scrum, RUP, whatever – it’s important that it allows you to deal with change effectively and naturally.

Without that, it just ain’t Agile.

PyGame Installation On Leopard

I’ve finally installed PyGame on my MacBook. I’m running OS X 10.5 and prefer not to use MacPorts or other builds of Python, so it was a little disappointing to find this avenue is not well supported.

It’s a particular shame as many people don’t find the need to use anything but the system Python these days, and many inexperienced programmers looking to try PyGame could be put off by the time-consuming process. In contrast, when I installed Pyglet a couple of years ago it was beautifully simple to do. I realise Pyglet is intended to be a simpler project than PyGame, but still.

Anyway, enough of the moan. For the benefit of others, I used two particular resources:

* PyGame Wiki: Mac Compile
* Frank the Blue: Installing Pygame on Leopard

I’ve used the latest downloads, some of which are newer than ones referenced in either articles. In particular, I substituted NumPy for Numeric and built the JPEG v8 library instead of v6. No problems so far.

London Python Code Dojo #6

Last night was the sixth London Python Code Dojo, and the third I have attended. Organised, as ever, by Nicholas Tollervey, hosted by Fry-IT and attended by many.

Unlike the previous dojo, the evening was run with one laptop hooked up to a projector and with a pair of programmers “on stage” for ten minutes to undertake a task. The original plan was to code for a maximum of ten minutes or until a unit test passed, then the driver-programmer would step down. Somewhere along the line we lost sight of testing aims. We also lost half the group to a discussion at the back of the room, while the front rows were engrossed in the problems at hand. Volunteers to join the pair on stage were a little sparse, and I must admit I held back a bit longer than I should have – once I was up, I had a throughly enjoyable ten minutes as Ciaran’s co-pilot, and was then very sorry when my own ten minutes in the hot seat were up!

So, what happened?

Firstly, the tasks of the evening were based around integrating the best core components of the previous dojo’s many solutions. A data file format and parser from one solution, the Cmd-based command line code from another, that sort of thing. While an interesting exercise in itself, it perhaps lacked the need for the creative approaches used last month. Work was primarily a copy and paste job, followed by some smoothing of the edges, with little need to sit down and think through a higher plan of action. The test-driven development idea got lost along the way too, and I admit furthering that loss once it had happened.

Secondly, group size had its effect. I don’t have a head count, but we filled the room as usual so probably about 20 people. It was interesting that those at the back gradually drifted into their own discussions and even ended up on laptops not looking at what was going on at the front. Even with a projector, it can be difficult to see what was going on and listen in easily to the conversations at the front between driver, co-pilot and hecklers. We use the term “hecklers” in an affectionate way in the dojo – there’s no malice or negativity involved with comments from the audience. I wonder if those who wrote the code being transplanted at a given time lost interest, since they knew the code already?

Extending from group size was group dynamics. With smaller teams like last week, it was easier for people to contribute: less intimidating than being in front of everyone, easier to have your say, easier to be engaged more. However, the single laptop approach does prevent hogging of the keyboard, and we’re all working on the same thing. Swings and roundabouts.

We finished with a wrap up of the situation and where we can progress for the next dojo. The team-based approach is going to make a return, and the delegation of different tasks to different teams sounds like fun – we’re still all working on the same final goal (an adventure game), the same code base, but we’re breaking up the chunks of work. That in itself will bring in some interesting extra skills such as integration and inter-team communication.

I think it was an important learning process, and one we needed to make this early in the project. Sometimes you need a setback to make you understand the dynamics of a situation and achieve a breakthrough. When I teach snowboarding, I often find those who go through a bit of a regression phase, a bit of a setback, come out with a much better technique and understanding than those who breeze through the lesson. We learn more from our mistakes than our successes.

Despite the problems, it was still a good evening – I had fun, met loads of cool people, got taken out of my comfort zone, learnt some new things. That’s a positive result in my opinion. I was rather excitable and involved in what was going on, so didn’t really notice what was happening until I was in the hotseat and could look out on the group.

The next London Python Code Dojo will be on Thursday 4th March. If you’re a Pythonista in London, come along and take a look – there’s free pizza and beer/Coke too!