“Sense Amid Madness, Wit Amidst Folly” (Surface Detail)

After 6 years (and change) of working with REA Group I have decided to resign. It’s mixed sadness and joy, as the place I joined all those years ago, is not the place I’m leaving. That’s good, and that’s also one of the reasons.

I’m moving to a medical genetic interpretation service called myDNA (http://www.mydna.life).  In short, people don’t always respond in the same way to medicines, and some of this is because of our genes.  In some cases we can look at our genetic structure and give additional advice to doctors about prescribing certain medicine.

I think this is pretty cool, and I’m actually going to be working on things that will make life better for people every day.  I’ll also be spending heaps of time working with software development teams directly, pairing with developers and improving their skills. At this stage it looks like I’ll also get to learn C# – which I’m pretty excited about.

One of the things that was important to me was being able to have a balance, and I’ve negotiated that with my new employer.  I’ll be working 4 days a week, giving me a day to pursue my own objectives.

I will be;

  1. Focus on providing mentoring/coaching for Women in Technology. From juniors who want to learn to code, to seniors who want assistance with CVs, with conference talk preparation or just general chatting about the state of the industry. I want to help. I want more women in the industry and I want it to thrive. I have 3 amazing women that I’m mentoring now that are happy to provide feedback should anybody be interested.
  2. Cycling.  Yeah.  A spare day a week to go cycling. Living the dream.  I suspect some of this will be consumed in housework.  I’ve made a deal with Mike Rowe that I’m going to ride the 3 peaks with him next year – so I’m going to need that extra time.
  3. Consulting.  If you’re a corporate, with a lot of money that wants somebody with 30 years of software development experience, team leading experience, AWS experience, privacy/security/cryptography and just general knowledge of the industry to come and give guidance, feel free to contact me and see if we can work out a deal.

From what I can tell, the office small, is open plan (but team sizes, not cattle-yard), and I get my own desk – that I can leave stuff on overnight, and have my monitors and keyboard and chair all set up how I like it.  I can have photos of Jo, and George stuck there, and gaze at them when I’m thinking.

I’m unreasonably happy about these little things, but it shows how much those sorts of things count as part of being a human.

The journey starts again.





2014 – Random reflections

I get to the end of the year and wonder what happened and then I feel like I didn’t actually do anything much over the year. This time I thought I’d put some effort in to reflect on what I inflicted on the universe for the year.


Starting with the most important part of my life. Life with George was again fantastic. He’s growing up into a wonderful human being. He’s so polite, so kind, so generous and just delightful to be with. I completely miss him when he’s not around. The best thing that happened in 2014 was a re-negotiation of our custody arrangements which gives me 6/14 (6 days out of 14) during the school year, and 7/14 during holidays. A great step forward, maybe 50/50 in the near future.

We have a good relationship. We’re both honest with each other about how we feel, and how we want to be treated. This leads to a few tough conversations at times, but they get easier, and pretty much all disagreements end very fast, and normally with lots of cuddles and “sorry how I behaved” – on both sides of the fence. He’s not the only one that has bad days, and it’s important to me that he knows that just a part of life and dealing with it as a family is crucial.

We have a house that we both love, his school is nice and close and we spend many, many hours a week playing cricket when we’re together. If we’re not off finding some nets, we’re playing keeping in the back yard, or watching it on TV. George loves cricket, and that’s been reflected by his achievements in playing with his new club. He plays in the under -10s, manages an average of about 20, top score of 40 (off 4 overs) and best bowling of 2/1 (off 2 overs). He’s only been dismissed once, and that was an overenthusiastic pull shot that ended up destroying the stumps. Oops. Pretty handy in the field and likes to keep as well. It’s great to see him doing well at something that he enjoys.

He’s going great at school, he works hard and enjoys turning up and doing different things with his friends. He’s a good little man.


Nothing really to report here. Both of us have avoided most of the really terrible coughs and colds, and despite both of our best efforts neither have managed to end up hospitalised for our recreational (mis)adventures. I’m fit and healthy, and after spending 5+ years being completely obsessed about riding bikes I’ve started to broaden my horizons to other activities.

I was finding it harder and harder to get consistently onto the bike looking while also looking after George. I’d need to spend a good 3-4 hours in the hills to get a solid workout, and that just wasn’t possible for much of the time. So after Amy’s Ride this year decided to take a break from riding for a while (to and from work doesn’t count) and in late October/early November started to look at running. Now, I’d not done any serious running for about 20 years when I used to run in 10km fun runs. The good news is that my cardio fitness base is solid, the bad news is that I’m missing a lot of muscle development for running.

At this stage, I’m pleased with my progress, getting to 4:30 min pace for 5km and 5:30 pace for 10km. Only time will tell how the body will handle it, as I’m already noticing a few niggles. Hopefully just related to lack of muscle development in those areas.

From a mental health perspective, I’m probably in as good a shape as I’m likely to ever get. Most of the anxiety and the pretty severe dent my self-worth took during the later parts of the marriage have been repaired. I’m still pretty nervous about what relationships might mean in the future – but I’ll cross that bridge when it happens. Soon, I hope.


This was a really big year for friends. Some moved within Melbourne, some moved to another country (I miss you Rup!) and some had some bad news. The best thing for me was meeting up with friends I’ve known for close to 10 years. I was able to travel to Blizzcon in November and got to hang out for a week with the most awesome group of people from all walks of life. It would be pretty safe to say that I really didn’t want that week to end, with geeking out about computers, gaming and drinking far too many beers.


There were 2 great things about work this year. The first was that REA started their graduate recruitment program, and I got to play a significant part in forming it, and getting the graduates on board and working with them. The second was that we finally managed to fill all the open roles in the Group Architecture team, and I can spend more time working with a team rather than trying to create it.

It’s fascinating working in the role that I have at REA, and it’s always challenging – most of these are people challenges, not technical ones – and I’m constantly left open mouthed at how some people react to change. I’ve blogged about my work a few times this year, I hope to do it a bit more next year.

Personal Achievements

It was a pretty good year on this front. I’ve been working on an open source project for a very long time, it’s almost part of the furniture in my life and I don’t give it much thought. It then pops up at unlikely times to make me re-evaluate what reach my software has had. The software in question is BouncyCastle. A Java cryptographic library.

  • It’s been shipped in over a billion devices as part of the Android operating system in 2014 alone (3bn total)
  • It’s being used by 12m people creating virtual environments in Minecraft
  • It seems that a large book selling and cloud computing company may also be using it for various things internally (unconfirmed)

So, at this stage there’s few people electronically connected that haven’t been directly or indirectly using software that I’ve written. That’s kinda cool and makes me feel pretty good.

I also managed to get back and do some conference speaking. Something I enjoyed doing years ago (pre-George) and thanks to Evan, Beth and the YOW! crew it was a great experience to do it again.


2014 was a good year. Probably one of the best I’ve had in recent memory. I’m feeling more balanced as a person and more comfortable in my role as a parent. I’d like to spend a bit more time on my personal projects as I feel my software skills are deteriorating below where I’d like.

Life is good. I’m very lucky.

You are not your ideas – a strategy to lessen the blow of rejection

Inspired by @dys_morphia on Twitter, I’ve decided to document my strategy for dealing with rejection of ideas. This particular approach came from a discussion with James Ross and Simon Harris many years ago working with on a consulting project.

James, Simon and I were discussing a bunch of ideas about design and implementation. We were thrashing through them thick and fast and each of us were proposing particular solutions which would be then unceremoniously torn apart by the others. To people outside our little gathering it really looked like we were intent on destruction.  Nothing could be further from the truth, as even though the other 2 are mostly wrong about everything and can’t see the genius of my ideas, as the respect for our work and our worth is paramount in these discussions. Few ideas survived the withering attacks, yet none of us felt harm, hurt or lacking in respect from the participants.

After we’d been doing this for a while, we started to reflect on why this is such an “easy” task for the 3 of us to perform, yet it appears to be very stressful for others. We talked a lot about rejection and about how people feel very close affinity to their ideas and proposals, and that rejection (or criticism) of them is like a personal attack.

James made this very clear explanation about how he thinks about ideas, and why Simon and I probably feel the same way – yet others struggle.

He said(*), “Many people hold their ideas close to themselves, their ideas are hugged, like a teddy to the chest, so any attack on the idea is in very close proximity to themselves and attacks hit not only the idea, but the person behind the idea. The idea is precious, there’s not many of them, and each one is special and nurtured and getting new ideas is a hard thing to do”.

This was compared to what we do, “We feel our ideas are like balls. We generate them, we toss them into the ring for people to observe and comment on. They’re cheap and cheerful and colourful and we know there is a bucket of them we can just keep getting new ones from. Sure, some are special and different in their own way, but the ideas are tossed away from our selves, and criticism of the size and colour of the balls are clearly not directed at the person”

I don’t want people to think that James, Simon and I are reckless, or foolhardy, or don’t care about our ideas. There’s often very heated debate about our thoughts, our dreams, our visions (and our fears) when we engage in these conversations. It’s just that we realise that our ideas have a life of their own, and it’s our job to bring them to life – we’re the parent of those ideas. We’re not part of the ideas.

If you’re an aspiring artist, a software designer, a poet, an author – or even just somebody trying to work out where to go for lunch, then consider setting your ideas free – toss them away and give them life of their own. You’ve already done the important work in the communication. You can’t be held responsible for how others react to your ideas, any more than you can be held responsible for other people liking your choice in bikes (even though there is a clear right answer here) and more importantly, by giving life and freedom to the ideas, you’re making it clear of a very important fact, you are not your ideas.

(*) I can’t remember exactly what was said, so I’m going to make up the story to convey the intent.

Micro services, what even are they?

This blog post was inspired by Jonathan Ferguson (@jonoabroad on Twitter) where the exchange started.

All the Twitters

@jonoabroad “Does anyone have an agreed term of what micro services is?”
@joneaves “Does it need one?”
@jonoabroad “yes. How is it any different to SOA?”

At this point, 140 characters was just going to make things harder so I suggested I’d respond with a blog post. So here it is.

Firstly, I’m going to start by saying I’ve probably got no right to be leading the charge for a definition for micro services, but I do have a lot of skin in this game, as it’s the direction that I’ve been pushing REA development for the past 2-3 years.  Much of this is my personal perspective, but I do think it’s broadly applicable and does provide what I consider an alternate viewpoint on the vision for micro services that exist. 

To answer Jonathan’s second question “How is it any different to SOA?”, my immediate response is “the intent is different”. With SOA, the intent is a layered architecture of co-operating services where SOA focuses on describing the organisation and co-ordination of the services. With micro services, the intent is to describe the nature of the services themselves and not quite so much the organisation and co-ordination of them.

While SOA is used as a comparison, SOA itself has no “one true definition” but merely a collection of patterns/principles and attributes regarding the organisation and co-ordination between services. I should point out that I see micro services and SOA working well together, with micro services describing attributes of the services themselves and SOA providing useful guidance on how to arrange them.

So, why do I think this way?

I’m a software developer, designer and architect. I like to think a lot about the human factors of software development and how can I put systems in place to encourage development teams to “do the right thing” when building software. There’s far too much shit software out there, and I like to have teams not contribute to that. With that in mind, why did I think micro services was a “good approach”? My definition is meant to be used to guide _development_. The benefits that we get operationally is wonderful – but that’s not the primary reason. It’s to get developers to stop building Borgified software with unclear responsibilities and brittle coupling.

First it’s probably worth providing my definition of what a micro service is, so that there’s at least some context around the discussions that may, or may not ensue. After defining the attributes, I’ll expand on why I consider them important.

Desirable attributes of a micro service is;

  1. The responsibility is narrow. The service does one thing, and one thing well.
  2. The code base is small. The service can be rewritten and redeployed in 2 weeks
  3. There is no 3.

I tried to think of more, but most of them were derived from these. A valuable attribute is the ease of upgrade and redeployment. This is directly related to #1. Another valuable attribute is the ease of change. Both #1 and #2 provide support here. There is also the ability for services to be re-used effectively. This is related to #1.  A person much smarter than I am once said “The unit of reuse is the unit of release”.

There’s possibly some rambly hipster crap about “REST services” and “HATEOAS” but really, that’s such flavour of the month and not really something that I think is that important. Certainly no more interesting than JSON vs XML vs ASN.1. All of these things can be done well, or badly – but don’t provide a defining point on if an implementation has desirable attributes.

The responsibility is narrow

This key point relates to design and the fundamental architectural principles. If the responsibility is narrow, then hopefully it follows that the codebase will be small. If the responsibility is narrow, then the understanding of where to make changes is clearer and design intent can be carried forward. If the responsibility is narrow, then understanding how the service fits in the broader network of services, or how the service can be reused is much clearer.

The second important part here is the ability to release the services often, cheaply and without needing to have a deep graph of dependencies. Having a narrow responsibility means that any systems that want to use the services are only coupled to that service for that responsibility. There’s no undesirable coupling. 

Like object oriented software, services are best with high cohesion and low coupling. Creating services as micro services helps in this regard.

The code base is small

When I first started proposing micro services I wanted to appeal to the developers, so I said that services could be written in any language they choose, The only caveats were that the component had to conform to our monitoring and logging interfaces (to aid with deployment and operations) and that it could be re-written in 2 weeks.

This created significant consternation, not by developers, but by management. They were concerned about the “explosion of software that nobody could understand”. I did laugh while explaining my reasoning. I laughed mostly because their basis of concern was that “it would take too long”. Sadly this shows the lack of understanding about software that pervades our industry.

Most developers are perfectly capable of understanding new syntax, and generally can understand new syntax in a relatively short period of time. What takes much, much longer is understanding twisted and tortured domain logic, scattered across 6 packages and libraries all bundled together in one monolithic application. 

My rationale is that if software is written according to the simple rules (narrow responsibility and small codebase) then the actual language choice is for the most part irrelevant in terms of defect fixing and extension. Sadly, I don’t have a lot of data points in this regard, as developers seem to want to choose the path of least resistance (which is normally keep writing the same old shit in the same way), but I do have a great example written by my team. 

We had the need to write a service and one of the team wrote it in Go. It was working well, performed as expected and when it came to adding some additional monitoring we hit a snag because the Go runtime wasn’t supported by NewRelic. The developer who wrote it had sadly departed the team (I still miss you Eric!) so another team member re-wrote the service and had it redeployed in 2 weeks. Written in Java, using Dropwizard. It was a perfect example of exactly what I was proposing.

There are some really useful patterns that we developed while creating the service, not really suitable for addition here, but if there is enough interest I can expand on it in another post. However, the way we thought about building the initial service and more importantly the automated testing around that service made re-development trivial, and incredibly safe.


Toy Robot Coding Puzzle

It may come as a bit of a surprise to many developers in Melbourne (and possibly other places) that I’m the author of the much loved and used “Toy Robot Test”. What may surprise people more is that it’s been around since 2007 and was written when I needed to evaluate a large number of hires for people at ANZ.

It shouldn’t be a huge surprise that it’s not entirely original – lets face it, nothing is. It was heavily influenced by the “Mars Rover” code puzzle that was in use at ThoughtWorks when I was there. I was also involved in hiring people at TW during this period and while I didn’t do this as part of my evaluation, I probably wrote and re-wrote code for this puzzle about 20-30 times as I explored different solutions so I could talk to candidates about it.

When it came to needing one for ANZ, it was all very familiar.

The other part of this that is also very familiar is the one question I keep being asked, which is “Shouldn’t we change it, it’s common and people could ‘cheat’ and copy the solution?”. To this I normally sigh, then start with telling a story all over again. This has happened again recently as one of our wonderful HR recruiting staff asked the same question, so I wrote her an email in response. I was chatting with a good buddy (hey there Travo) who asked me about the code puzzle in a similar way, I showed him the email.

He then suggested that I post my response in a blog. It seems like a good idea, but it’s probably worth understanding how the code puzzle works in my recruitment pipeline. It’s the first filter, which is quite unusual for many people (something else I often get asked about).

Why? Well, the sorts of filters for somebody you want to hire as a software developer are;

  1. Are they a competent software developer?
  2. Are they an asshole?
  3. Can they cope with working with/near me?

In my life experience, people are generally not assholes. So as a result, doing some form of “phone screen” or “cultural interview” first is pointless – because it’s really, really likely they’re a nice person who you’d enjoy hanging out and having a beer/wine/halal drink of choice with. However, if I’m going to hire them as somebody who will write code that’s pretty important. So, I figure – maybe I should ask that. And, in my experience, most people are *fucking terrible* at writing code (no really, you all are, deal with it).

So, I use the filter that’s going to let the smallest number of potentially non-asshole people through. Then I can chat with them about technical stuff and I can do things like work out exactly how much they do know about technology, if they’re smart and use emacs, and other important things like keybindings and directory structure preferences. Also, doing this gives them a reasonable idea about what it might be like to work with me. So, that kinda sorts out 2 and 3.

Apart from letting some Scala people through this process when even I was too naive to think people would use that borg of a system, it’s worked pretty well. So yeah, the point of this blog post – why I don’t care that the Toy Robot Coding puzzle is well known.

Hi Jon,

Can we write a new Robot puzzle please?



Hiya (redacted),

I suppose I’m trying to get you to articulate why you think you want to do these things.

You’re telling me things about what is happening (which I already knew about), but there’s another part to this that I want to discuss with you, but I want to understand what you want.

 I suspect that you’re worried that people are going to “cheat” the code review and that’s why you want it changed. I’ve had this discussion with everybody since I started doing this – so it’s by no means a new conversation.

Now, this is the very funny part. The general quality of responses from candidates is so poor that they’re too ineffective to even copy a good version of it. Think about that for a minute. Most of the candidates are incapable of copying a working solution to try and “trick” me. What does that say about most programmers? It’s a pretty sad indictment of our industry that they can’t Google a good solution, modify slightly and understand what was written enough to trick me through an interview. It’s embarrassing.

There is also the problem (regardless of what we do) where somebody else can write the code for the candidate.

Now, this is where we have a conversation with the candidate and ask them about the code. Turns out if they didn’t write it – they don’t know how it works, or how to extend it, or how to talk about the potential design issues with it.

Our potential outcomes are as follows;

  1. Candidate is able to complete code puzzle honestly and “passes”
  2. Candidate is able to complete code puzzle honestly and “fails”
  3. Candidate copies from github and passes
  4. Candidate copies from github and fails
  5. Candidate has submission written by 3rd party and passes
  6. Candidate has submission written by 3rd party and fails

Now, our recruitment process will treat 1,3,5 as identical and 2,4,6 as identical during the code review phase. Of course, obvious copying of the wrong names etc may make for great amusement but is otherwise undetectable.

2,4,6 we don’t care about – because they failed anyway

Of 1,3,5 we really need to try and identify 1 separately from 3 and 5, as 1 is the candidate we are at most interested in progressing with.

 If we examine the characteristics of 3 and 5, we notice that they are the same. It’s really just “code not written by the candidate”. So, if we choose a different puzzle we are under the incorrect assumption that it will somehow make it “harder” for the candidate to cheat – but option 5 is still untouched.

So, that’s why we talk to the candidate about the code. In depth, and often with reference to the design decisions they have made (or not made) and ask them about how they would extend it.  This allows us to detect both 3 and 5.

Having said all of this, I hope you can understand more about why “changing the code puzzle” really doesn’t matter at all. We can change it for other reasons (such as a different problem for the fun of it) but having an “original” problem doesn’t mean anything in terms of improving our hiring decision strategy.

Going paperless

I decided to go paperless at home, and have purchased a scanner and going to digitise all the random pieces of paper I get during the year.

I’m wading through all my tax from last year and realise that it would be a lot easier if I didn’t have to shuffle the papers around, and store them.

If you’ve done this – what are some good pieces of advice you can give? I don’t plan to scan receipts, maybe bills. What should or shouldn’t I bother with?

Providing a framework for communication

A lot of my work at present is helping the technical leaders of our business aligned groups do their work effectively. There’s lots of communication individually, and as a team.

Having all the smart people (and me) in a room greatly aids decision making, but one of the most valuable communication aids that I’ve implemented is describing responsibility and accountability in terms of bounded contexts.

Eric Evans uses this term in Domain Driven Design to separate out modelling concepts and to try and stop the “grand unified theory of Customer object definition”. What I’m using the bounded contexts for is to describe the areas of accountability for the tech leads and say “whatever happens inside that boundary is your problem, but you have to communicate to other contexts using my rules”.

So far, this has been working very well. It really helps in guiding the communication to “what bounded context should this functionality logically be located” and hence the ownership.  Then, the tech lead working in that area is completely free to implement the functionality according to their methods, exposing the interaction via an interface that is “proscribed” (but generally we thrash about as a team defining what this will look like).

As I was trying to describe this process internally to managers at REA, I found that this article (http://gorodinski.com/blog/2012/04/03/bounded-contexts-as-a-strategic-pattern-beyond-ddd/) provided a nice starting point.