Agile

[caption id="attachment_4529" align="alignnone" width="339"]Like two-time WWE Champion Daniel Bryan, Javascript demands respect Like two-time WWE Champion Daniel Bryan, Javascript demands respect[/caption] Yes, it's true. Javascript is so popular it can now be a full-time job. Many people used to coast through their daily jobs as a PHP, Rails, Java developer with a few $(..) statements, maybe a $('#message').hide() (or a $('#message').slideUp(); if you were hip). But these days, Javascript is coming of age. It's grown from being a scrappy little toy we have loved and abused with code like onclick="alert('...')", to be something that has grown up with us, and now appreciate. It is the only runtime language I can think of that will run on any modern processing device. It's ubiquitous and the ecosystem has evolved beyond what anyone could have imagined, with many implementations (Rhino, V8, now Nashorn) and it's very own matching server-side equal, node.js
Fork in the Road

I work in a team that is constantly faced with the challenge of getting features approved for release into production. This is largely because the business is very fast moving, and business priorities change often. As priorities change, the focus of the business shifts from feature to feature, so resources for testing and approving features can be scarce. Consequently, our trunk codeline contains approved and unapproved features. This becomes a problem during our releases, because unapproved features have to be removed from trunk, which as most developers would know, is a painful process that results in dozens of conflicts.

In this blog I will present a solution to minimise the problems surrounding unapproved features in the codeline at the time of a release. This solution involves having a separate branch that only contains features that have been completed and approved by the business. I will also contrast this approach with popular alternatives like Feature Branching and Feature Toggling.

yow2012logocitieslarge This year was my first attendance at the YOW! Conference, and I am very happy I was able to go. The conference was well-organised with great speakers and thought-provoking presentations. Fascinating to me was that several themes recurred in different presentations at YOW!, with each speaker giving it a unique angle. Watching several presentations from different experts in this conference setting lent itself to a meta-analysis of these themes. One that I found particularly interesting is risk management for software projects; specifically, how development processes can help businesses manage the risks.
Working on a project that used pair programming was something that I'd wanted to try for a long time but had never had the opportunity to do. Consequently, when a chance came up to work on a project where the entire team was pair-programming full-time, I was ready to get on board and give it a go. In this post I'll talk about my experience, some of the benefits I saw, and some broader conclusions that I reached.

Some people love it, others hate it - many people just don't get it. So what is Test Driven Development ? Wikipedia has a page on it, there are heaps of blogs talking about it and our own Ben Teese has put together a great...