Saturday, 29 December 2012

Visit to Melbourne

Visited the beautiful city of Melbourne for the first time in December this year. This was mainly for business, but I managed to get some sightseeing in also. The primary purpose of my visit was to meet with REA Group's CIO - Nigel Dalton - and take a look around their Agile implementation. This was certainly a worthwhile expedition.

[Q: some trivia - I happened upon this device on the side of the road in Melbourne, what do you think it is used for (took me a little while to figure this one out)?]

If you're interested in Agile at all and you ever have the privilege of  attending an event at which Nigel is speaking (he's a fantastic speaker BTW), see if you can have him invite you for a tour of REA Group, or alternatively, his latest Agile initiative. Nigel is known affectionately I believe, as Australia's "Mr Agile" - I can see why now. I'm uncertain as to how free I am to discuss the ways that REA Group are applying Agile on my blog, however I can certainly say that they are applying the Agile philosophy in some highly innovative ways and are actively pushing out the boundaries of contemporary Agile application. Unfortunately my visit to REA Group was cut short due to my being more than an hour late for my allocated timeslot (sorry Nigel!), however the short time that I had with Nigel was enough - I came away feeling enlightened and with a refreshed sense of inspiration and affection for Agile, to say the least.

Of course, as I mentioned, I got to do some sightseeing around Melbourne also. Didn't have much time to spend, but probably the highlight for me would be looking around the art on display at the Ian Potter Centre, and also simply wandering around the various neat little alleys and side-streets that Melbourne seems to be so rich with.

[New York style news-stand in Melbourne]

[Amazing Aboriginal art at the gallery]

[Street-art in one of the many nooks-and-crannies in Melbourne city]

As a city, Melbourne does not make much sense to me, geographically. We also visited Sydney while in Australia, which gave me further food for thought on the matters of city-scape and geography. I am essentially a person who does not like to lose his bearings (or even feel slightly disoriented) - I am generally fascinated by maps and geography - however I have only pinpointed the source of my underlying sense of confusion about the place since I returned from Melbourne and meditated on the matter. It's not an easy concept to explain, but here goes...basically, I am born-and-bred in Auckland and Wellington in New Zealand - and I guess I have developed neural networks optimised to these "type" of cities - both of which are what I would describe as harbour-oriented; that is, they have a definite "front" and a "back" to them. There is a true sense of direction to Auckland and Wellington (and Sydney), in that, the whole city slopes down toward - and is centered about - the harbour. As you get closer to the harbour, the city gets bigger and flashier. With Melbourne though, there is no real centre or focal point to the city - although it has a river running through it and it is close to a significant body of water (Port Phillip Bay), Melbourne really does feel a lot more similar geographically to say, Kuala Lumpur (or perhaps Guangzhou) than it does Sydney. I found Kuala Lumpur hard to navigate also! Despite all this, Melbourne is a lovely place, as I'm sure Bolte and Dunstan would (have) agree(d). I look forward to visiting again (and spending a bit more time) in future.

[Bolte and Dunstan - late/former Victorian Premiers]

While I was in Melbourne (and sort-of as an extension on the matter of geography) I also visited a family friend - Erjiang (Frank) Fu - at the Australian Bureau of Meteorology. Frank and his colleagues at the BOM are also using Agile, which was interesting, although they are using it mostly for operational purposes. It was interesting to hear about some of the significant GIS (Geographic Information Systems) projects Frank is working on - certainly from an NZ perspective they are much larger than any local GIS initiatives that I am aware of. Frank also tells me that the BOM website ( is within the top-10 most visited websites in Australia - I guess people are pretty keen on the weather in Australia, which is not really surprising given the size and scale of the continent/country and the range of environmental extremes it offers up.

[A: these guys! As one of my daughters pointed out just now "Hey, that's where the horsies drink!"]

So many thanks for your time Nigel and Frank, and thanks Melbourne for showing me an interesting time in the few hours I had to visit.

Friday, 2 November 2012

Transit of Venus

On the day that Venus was visible transiting the sun (June, 2012), I took an afternoon off work - and my son actually had the day off school - the idea being that we were going to go to the observatory on Auckland's Maungakiekie (One Tree Hill), in the hope that we would be able to use one of their flash telescopes to view the event.

I wanted my son to be able to see the event especially. I clearly remember my dad waking me up at about 4:00am one fine night in 1986 to see Halley's comet. I wondered what the hell was going on - we were standing on the driveway of my grandparents home in Birkenhead looking at the sky with a pair of binoculars in our dressing gowns. I distinctly remember thinking that it was relatively warm for the dead of night.

Sure enough though, we eventually found the comet. I've done a quick comb of the web looking for images that somewhat resemble my memory - closest I can find is this one:


It was a smudge in the sky, but there was no mistaking the comet - it was for real and it was magnificent.

That was one of those events that I'll remember for the rest of my life; like a lot of boys I guess I was (and still am) more-or-less naturally interested in all things sciencey, spacey and techy. Certainly at some level this event helped reassure me that there was real value for me in pursuing those early aspirations to work with technology. I wanted to create an experience like that for my son.

Unfortunately though, the skies were cloudy when we got to the observatory, and it wasn't looking like clearing for a while. So no such luck there. Instead though we bought a pair of "eclipse glasses" like these ones, and headed home:


At home I worked remotely from for the rest of the day. Late in the afternoon, toward the end of the transit (which I was tracking intently online) there was a hint of a break in the cloud - a noticed a few shards of sunlight coming through the window. And sure enough, we were fortunate enough to have a clear spell of a few minutes just before the end of the event - we saw the planet!

To me events like this are very special and to be treasured - I think that they help remind us of the scale, reality and nature of the universe. They provide the opportunity and motivation to think beyond the day-to-day matters of our lives and consider and address the matter of our existence and our place in the universe - literally, the greater scheme of things. To see with my own eyes the circular profile of our neighboring planet making it's way across the backdrop of our star was amazing. To watch and consider the three/four dimensional nature of the experience - Earth, Venus, the sun, the force that the sun exerts to hold the system together and the steady velocity of the planet - was, well, more than words can describe. As I watched (I couldn't get enough of it) I could almost feel the ever-so-slight re-writing of neural pathways occurring in my brain. What an experience.

When I saw Halley's comet I was about 11. My son was 7 years old at the time Venus transited the sun (in June this year); unfortunately he didn't really understand what he needed to look for and I'm pretty sure he didn't actually see Venus, which although clearly visible by the naked eye, required a bit of concentration to spot.

He did see however - and was genuinely amazed by - the clear and perfectly circular disk of the sun, through our eclipse glasses; as did my daughters. My wife saw Venus - she was rapt by that. So we all got something out of the event - it was a great success, the drama was heightened by the fact that we had sort-of waited all day and finally got a few minutes glimpse through the cloud at the very end of the event, in the late afternoon. I can't help but feel just a little bit sad that my son missed seeing the planet. But he was only 7 (I doubt I would have understood what was going on at that age either) and there's lots of time and astronomical events yet to come in his life.

So, this is pretty much what the transit looked like though our eclipse glasses - this photograph was taken from Waterview or Point Chev I think, not by me:


...and here's a photo that I tried to take myself by putting the eclipse glasses over the top of the lens of our dodgy old Kodak camera:

Yeah, you can't really see what's going on there - what we saw was much more like the clearer image above.  But, you know, at least I tried!

Next up, I hope that we will be able to make our way sometime over the next few years to somewhere on Earth to watch a total solar eclipse. There's no good ones in NZ for a couple of decades. So we'll probably be travelling for this one I think...

Friday, 19 October 2012

Consciousness and the Illusion of Control

Here are some thoughts that I had on the way to work this-morning.

Life as an explosion

The phenomena of life can be thought of as an explosion - physically, life is essentially a self-sustaining chemical reaction; evolution is a bloom of chemical diversity. Once the process is ignited, potentially starting from a single point - the reaction expands outwards, increasing exponentially with time, in volume and complexity.

[Tycho supernova remnant -]

Consciousness and the illusion of control

In the same way that the various components and structures that can be observed as part of a "conventional" explosion have no control over themselves as individual elements of the larger process, it is difficult when thinking of life in this context, to believe that life should have any control over itself. Also, thinking in this context, the event and development of life is inherently and inextricably connected to every other part of itself.

Consciousness and self-realisation then, can be considered an aspect and result of the increasing complexity of the explosion. So, can we think of consciousness as being like the universe observing itself in a mirror?


This thinking does not take into account or consider anything beyond the limit of our current understanding of our physical environment, nor does it aim to.


EDIT: 20130911 - changed the name of this post from "Not sure how to relate this to technology -" to what it is currently.

Sunday, 14 October 2012

Conflicting Business Requirements and Skateboarding

I am a skateboarder, and while out for a roll with my partner in crime (pictured drinking a fruit juice, below) today we came across this concrete block - which I believe represents a textbook study in conflicting business requirements, and is proof that the phenomena isn't limited to software engineering.

If you look closely, you'll see that the concrete block is equipped with a nice seat, and also, metal edging - what's that edging about? Well, the edging is specifically for the purpose of skateboarding - for example:

[This chap is doing a "nosegrind" - note the metal edging on that block...source:]

It's actually a fantastic idea, and one that has been used recently in other parts of Auckland and Wellington cities, I've noticed. Skateboarding is encouraged by doing this; which I think enriches the city's culture and enables creative/innovative use of features of the urban landscape, that would otherwise be for aesthetic purposes only.

Interestingly (and aside from the point of this post), and entire industry seems to have sprung up in recent years directed toward "skateboarding prevention" - that is, the deterrence of the use of concrete blocks for grinding/sliding/etc - here's an example:

["Skateboard Prevention Device" - source :]

...shame on them! Anyway, this is a departure from the point of the story...

So, yes - putting the metal edging on the concrete block is a great idea - full credit to whoever thought of that. And it works really well, right up to the point where the pavement surrounding the block has been carpeted with a very fetching, coarse red gravel - rendering the ledge un-skatable (gravel doesn't take kindly to skateboard wheels).

No doubt there is a satisfied councilperson blissfully signing off on a several thousand-dollar invoice to have metal edging added to this concrete block, while quietly patting themselves on the on the back for promoting urban culture and enabling a creative environment. And good on them too, that's awesome - maybe just give those business requirements a(nother) once-over before signing-off next time, aye people? 

The moral of the story? Technology people; take consolation in the fact that you're not the only ones who suffer from conflicting business requirements!

Here's the location of the block FYI, in-case you'd like to see for yourself - downtown Auckland, near Victoria Park (you can see the block in Google Maps there, bang in the middle of the picture):

View Larger Map

Thursday, 19 July 2012

An Emotional Year of Scrum

At CallPlus we're coming up to having completed a year of software development using Scrum. It's been an emotional ride. All things considered, we're better for it in my opinion, and my impression is that that's the opinion of most people in the organisation. I did a talk at the Auckland APN (Agile Professional's Network) Meetup last night - for me, this marked the milestone nicely. Prior to the talk, a recommendation was made to me to run the talk using an "emotional chart" showing the development team's happiness level in relation to our Agile implementation, as a guide for the audience. I thought that was pretty neat concept and certainly worth a try - it was received well - here's the chart I put together:

I call it the "Agile-o-meter". It shows that the transition to being Agile is difficult and fraught with the possibility for things to go wrong. We certainly failed (fast/early?) on our first attempt. This chart is my interpretation of the emotional state of the Team as we moved toward being Agile. The two prominent local maxima in the chart (at approximately horizontal point 1 and point 2) show where we crashed an burned with our first attempt at Scrum, and then subsequently nailed it, with the help of a Scrum Coach. The peak of the second maxima is where we effectively reached the end of our budget for Scrum Coaching and went it alone - we learned a few lessons the hard way (for example that running a Retrospective is really really important!) before we started tracking up again.

The reason I've made the chart a bit fuzzy is to emphasize the fact that this is pseudo-science - it's my interpretation of how the Team felt a certain stages in our implementation. The Scrum practitioner who recommended that I use this chart to "guide" my talk said that he knows a ScrumMaster who does lierally track/measure his Team's happiness level Sprint-on-Sprint; he takes a measure from each Team member from 1-to-10 and uses the output as a tool to see whether things are going OK, or not, then tease out discussion on what's upsetting people, etc. Great idea, I think we'll give it a go.

Tuesday, 26 June 2012

Agile Estimation

Is there something in the nature of the personality of the developer that causes them to feel the need to under-estimate their work? Is it the fact that developers enjoy their work so much, and are so anxious to be able to continue to be paid to do what they enjoy doing, that they more-often-than-not tend to see the world through rose-coloured lenses when it comes to estimation? Possibly it's both of these, also probably it's to do with the fact that software development is an exceedingly difficult and complex thing to whack an estimate on unless it's done in very small chunks.

With it's well defined toolkit tailored for just these type  of complex problems, Agile has built a reputation for kicking arse and taking names when it comes to software estimation; at least, it has in my experience. Let me count the ways (that Agile breaks it down):

- Epics
- User stories
- Tasks
- Story points
- Planning poker
- Sprints
- Acceptance criteria

...and the list goes on. Many of these artifacts are Scrum specific, but all of them are about clearly defining, measuring and decomposing big chunky pieces of work into manageable, measurable, increments of achievable cool stuff.

Looking back and remembering the stress and uncertainly that used to be part-and-parcel of software estimation (and delivery on an estimate), I find it difficult to believe that I made it though my tenure as a developer to tell the tale (that is, I didn't change professions). I guess I enjoy programming too much.

[the dreaded "cone of uncertainty"]

I have seen the change that the introduction of an Agile approach makes in a business and in a Team of developers; it is somewhat revolutionary. As a manager of developers, I get to share the benefits. I think that one of my Team members summed it up best by saying that "Since we have launched Scrum I've been a much more relaxed person". Agile is not easy, but it can make things easier.

I'm going to have a crack at writing about Story Points and Planning Poker in a future post (soon-ish) - a couple of particularly interesting Agile estimation artifacts.

Sunday, 13 May 2012

Our planet does not need to be saved...

Every species that humanity pushes over the line into extinction is a lost opportunity to learn; billions of years of evolutionary process went into optimising the behaviour and form of that creature, the only way we can learn about that particular tendril of the evolutionary tree following extinction is to study remnants, echoes, fossils. It is important for the survival and optimal development of our species to only let this happen if absolutely necessary – but not to prevent it at all costs.

As far as we know, Homo sapien sapien are the only species on earth who have ever reached a point of such complexity in the evolutionary process where we could intentionally and realistically, start to propagate the life that has developed on our planet to-date, across space and onto other worlds. We could do that today. We may have done it already, unwittingly – there could be colonies of terrestrial bacteria developing and evolving on Mars, Titan, perhaps even the Earth’s moon, as I write.

Life on Earth is constantly – and has always been – running a gauntlet. Every few million years, an asteroid or comet strikes our planet – a direct hit. When that happens, most complex, highly evolved life is wiped out. The process is reset. It will happen again, maybe tomorrow, there is no “if” – just “when”. We have no reliable way to tell “when” and even if we did, currently it probably would not make a hell of a lot of difference – depending on the force of the impact, our species (along with many others) could be wiped out, regardless.

[Vredefort impact crater, SA (2 billion years old) -]

As I see it, it is naive to say “save the planet”. The planet has seen far, far worse than Homo sapien sapiens; she has the scars to prove it. Don’t worry about that. What we need to think about is how we can optimise the rate of development of our species’ technology in a way that will enable us to preserve as much of the precious and fragile life that has developed on Earth as we can – the ultimate objective being extra-terrestrial propagation and thus, redundancy.

[edit: 2013-05-01]: Clarification on this matter is here -

Tuesday, 17 April 2012

Programmers who "care" vs $2-shop software.

There is something to be said for the experienced coder who is capable of producing low quality software at a fantastic rate. As a programmer who cares about software, it can be easy to get caught up in the idea that software must always be thoroughly tested and beautifully architected, appropriately apply design patterns, separation of concerns, and all the rest of it.

Whereas sometimes, a business needs a rough-and-ready, potentially high maintenance solution, until such time as either a venture stabilizes or, alternatively, crumbles away.

[EDIT 20121030: in New Zealand, we have a chain of shops called "The $2 Shop" (, which sell very cheap stuff that doesn't last very long but is good if you're in a hurry]

The work of a $2-shop programmer is often ruthlessly ridiculed by programmers who "care" (that is, programmers who are accustomed to applying a quality/craftsmanship oriented approach to their work). The $2-shop programmer however relentlessly and undeniably produces lots of working software - it's just that it's difficult to maintain, and augment.

$2-shop software however - whether it's written by a keen business owner, or by an opportunist contractor who learned VB from a web tutorial - can often end up being the core of a bigger system. This is because, as a business venture stabilizes, it attracts higher quality (more stable) programming, resulting from the desire to make the process more robust ans scalable, for the longer term. The trouble is that businesses may not be inclined to significantly refactor existing software infrastructure and instead opt for high quality clip-ons to an existing, $2-shop core.

Herein lies the problem. If a business wishes to attract quality programmers, it needs to be open to the idea that they are most likely going to want to refactor $2-shop code when they come across it, in the same way that if you were investing in extending a house you would want to address hazardous electrical wiring in the process.

If a business with pre-existing $2-shop software infrastructure (let's face it, this is most of them) is willing to take this approach - that is be open to investment in significant refactoring, and trust it's programmers to advise as to where this is appropriate - then it (a) introduces a short-term cost and (b) sets itself up for long term stability.

In summary, I think that there is definitely a place for $2-shop programming - it is in the realm of prototypes, high risk ventures, and where there are significant gains to be made by acting very fast. And for the resulting $2-shop software to become part of a sustainable and scalable business model, businesses must accept the cost of refactoring.

Friday, 6 April 2012

Eclipse/Android error: "Multiple dex files define [...]"

Wow, I am really going nuts blogging this-evening - 2nd post in less than an hour. 

Anyway this is a particularly nasty error that I keep running into with Eclipse/Android when starting the emulator after I have not run it for a little while. Since I run the risk of permanently forgetting the solution to the problem every time I walk away from my Android project (and thus having to spend a painful hour-or-so digging up the procedure again), I will blog it here, for my benefit, and for the benefit of anyone who may also suffer the same problem.

The gist is that when you start the emulator in debug mode (that is, you hit the button in the following image), you get the following error message come out on the console and a nasty popup telling you nothing more than there is an error with your program and you need to fix it:

[2012-04-06 23:20:57 - Dex Loader] Unable to execute dex: Multiple dex files define Lcom/google/gson/ExclusionStrategy;
[2012-04-06 23:20:57 - SimpleList] Conversion to Dalvik format failed: Unable to execute dex: Multiple dex files define Lcom/google/gson/ExclusionStrategy;

Perhaps you're not using GSON, as I am, but some other library or archive. My understanding is that this issue is not limited to GSON.

So, the way to deal with it (which so-far seems to work without fail for me), is to go to your project directory and delete all files with the suffix "dex" or "apk", and then restart Eclipse. I have no idea what the cause is, but this seems to do the trick. Good luck!

Family Scrum Board

First Sprint started today, ends Sunday evening.


  • Some tape.
  • A printer and Word.exe.
  • A marker.
  • Some knowledge of Scrum/Agile.

Let's see how this works out...



Sunday, 25 March 2012

Agile NZ Conference - April 2nd/3rd

I'm doing a talk at the Agile NZ conference in Wellington in a week's time - come along if you're in the area, it's bound to be useful if you have any interest whatsoever in the Agile movement.

My talk will focus on the Scrum implementation that we've recently done at CallPlus - here's the blurb:

This presentation takes the audience on a journey; it recreates, as much as possible, a feel for the situation at each phase of CallPlus’ Scrum implementation experience. The intention is for the audience to come away feeling enlightened and empowered. It will mostly focus on the Team and the “human” experience of impementing Scrum.

1. Inception
  • When did we start thinking that Scrum could be a good fit for CallPlus? What was it about Scrum that appealed?
  • Winning the support of the business – how did we win the support of key stakeholders, and how did we accommodate hesitation and uncertainty among business leadership?
  • Analysis of our failed first attempt at compiling a Product Backlog and performing Sprint Planning. What did we do wrong? What lessons did we learn?
  • Realisation that we needed coaching - how we determined what the right fit was for our organisation, how we source and engaged a coach and worked with them to tailor a suitable program.
2. Implementation
  • Second and third time’s a charm – launching Scrum, for real. Running up two Scrum Teams, one after the other.
  • The rocky road to success – repeated incomplete Sprints, Product Owner disarray, Team dissatisfaction, the light at the end of the tunnel, introduction of dedicated ScrumMasters, dedicated Product Owner(s), complete Team buy-in.
  • Our first 100% completed Sprints and the gradual lockdown of the process through Sprint retrospectives (inspect/adapt).
  • Realisation that greater investment in coaching would have oiled the wheels much better.
  • The 6 month milestone – approaching complete business buy-in, and CEO sanity check.
3. Retrospective
  • Analysis of the benefits that Scrum has generated for the business and the development team. What specifically about Agile/Scrum generated these benefits and how can we actively capitalise on that.
  • Analysis of the challenges that we continue to face with Scrum;
4. Looking forward
  • Agile – as is suggested by the Scrum Framework itself - is an ongoing journey of iteration, inspection and adaption. Broadly speaking, how we intend to improve our practice.

Will post the slide-deck following the session - I'm currently busy finishing it off! Here's the programme, the event run across April 2nd and 3rd, and is hosted in Wellington.

Migrating (and Open-Sourcing) an Historical Codebase: SVN-to-Git

I have a SVN repo on my local machine that I have been shoving stuff into since before I knew how to use revision control systems properly (...