Murphy’s Law Should Appear In Every Line Of Your Code

A graphic from a 1930s German pamphlet showing a woman being electrocuted because she touched an overhead lamp and a gas pipe at the same time. Murphy's Law aims to stop these kinds of catastrophes.You know Murphy’s Law, right? Or at least you know the way most people remember it: “Anything that can go wrong will go wrong.” It’s a fairly depressing way of summarising life, but we all recognise a large portion of truth within it. Things go wrong. All the time.

There’s actually contention over whether this is the original form of the law, which is named after aerospace engineer Capt. Edward A. Murphy, and there are several differing accounts of how the saying came about. My preferred account is that relayed by Australia’s Dr Karl Kruszelnicki, whose record of Captain Murphy’s original exclamation is:

If there are two or more ways to do something, and one of those results in a catastrophe, then someone will do it that way.

I like this version because it’s easier to see the qualified optimism that Murphy juxtaposed with his frustration. As Dr Karl explains, there is a hope embedded in this form of the law because it starts with a proposition: “IF there are two or more ways to do something…” Continue reading

10 Reasons You Shouldn’t Have Senior Developers, Tech Leads or Architects

Two weeks ago I published a post titled ‘Why Smart Software Teams Don’t Need Senior Developers, Tech Leads or Architects‘. I received a lot of good feedback, but I also know it was a long read. So, if you’re interested by the title but are looking for a quick brain dump rather than an enjoyable read, here’s the abridged version:

At Tyro Payments, we’ve doubled our Engineering team over the last year.

We don’t hire for, or use, titles like Graduate Developer, Junior Developer, Senior Developer, Tech Lead or Architect. Everyone has the title ‘Software Engineer’.

This is an important part of Tyro’s Engineering team culture. Here are the reasons… Continue reading

Why Smart Software Teams Don’t Need Senior Developers, Tech Leads or Architects

Queue for Steve Jobs' keynote at WWDC 2010

A queue of software developers, not unlike the one that has inundated my inbox for the last year.

We’ve almost doubled our Engineering team at Tyro Payments over the last financial year and we’ll be adding that many again this year.

Most people who’ve worked in or with software teams would imagine that within this surge of hiring we’ve been filling all kinds of different roles – Graduate Developers, Junior Developers, Seniors, a couple of Tech Leads, maybe an Architect. But the truth is we’ve only been hiring for one role: Software Engineer. In fact, it’s the only development role on our team, and it’s the title we give to everyone on the tools, whether they have 20 years’ experience or none. This isn’t just some convenience we came up with to save ourselves HR work. It’s an incredibly important part of the culture at Tyro. Why? Continue reading

Meetup Digest: Sydney FinTech Startups (April 2013)

I went along to the Sydney FinTech Startup Meetup for the first time tonight.

Keyboard keys spelling out 'money' sitting on top of a lot of coinsIt was an interesting meeting as the speakers were all from the Westpac Group, one of the biggest, oldest companies in Australia, which hardly seems appropriate to the Startup scene. However, the guys had a lot to say about how they see the current banking markets and what the bank’s take on innovation and interaction with small companies looks like. From my point of view (as an employee of a financial startup that’s recently hit profitability and is now entering a scaling stage) it was interesting to listen to the challenges that these big companies face and to think about how we might try to avoid the same traps as we grow. Continue reading

Survey Results: Are Developers More Productive In Scala?

The Story So Far

Lots of numbers in different fonts and coloursAbout two weeks ago, I wrote a blog post suggesting that Scala can make Java developers more productive. One of the comments on that post was that I had no metrics and so was spreading “folklore”. I took the criticism constructively and decided to solicit a small survey of Scala developers to try and get some insight.

What I Wanted to Learn

One of the most important things I’ve read about Lean Startups – and it’s important because it can be applied to a gamut of contexts, not just startups – is that, while the execution of the Lean process is Build, Measure, Learn, you actually have to apply this backwards to get good results: first you decide what you want to learn, that will inform what you need to measure, and that will determine what you need to build.

I employed this advice with this survey, asking first: “What do I hope we learn from this”, and using that to inform the content. Here are the questions for which I wanted the survey to provide some insight: Continue reading

Are You More Productive In Scala?

JugglingUpdate: The survey has closed and you can have a look at the results here.

Yesterday I wrote a blog entitled ‘A New Java Library For Amazing Productivity‘, which was – in all honesty – a trap: a well-intentioned honey trap with the purpose of trying to convince developers that they should be looking at Scala and evaluating it on the merits of its potential to deliver productivity gains, just as they would with a library or framework, rather than discounting it because it’s a “language”.

One of the comments I received was from Stephan Schmidt who writes the ‘codemonkeyism’ blog. Stephan wrote:

The sad state of our industry: Folklore.

Huge claim: “A New Java Library for Amazing Productivity Posted on February 11, 2013″
No facts or numbers. Continue reading

A New Java Library for Amazing Productivity

I’ve found this great Java library that can make developers more efficient in pretty much every source file they write. It has the following features:

  • Ferrari 458 Italiaa broad and powerful collections framework
  • collection methods that greatly reduce boilerplate
  • immutable collections that don’t have mutation methods (unlike java.util classes where e.g. List.add() throws an exception if the list is immutable)
  • an awesome switch-like function that doesn’t just match numbers, enums, chars and strings, but can succinctly match all kinds of patterns in lots of different classes, even in your own classes
  • an annotation that automatically writes meaningful equals, hashCode and toString methods for classes whose fields don’t change (without using reflection) Continue reading

What is DevOps? … in bullet points, quotes and tweets


Interest in DevOps is booming. I feel like I heard it mentioned as the motivation for some decision at least once a week last year, and it climbed its way into the headlines of most of the newsletters I receive from LinkedIn, Twitter, InfoQ, etc.

Army soldiers pulling hard on a rope in a tug of war. Teams working together in a DevOps environment concentrate on all pulling together in the same direction.

I thought I understood it. It just means Dev and Ops collaborating closer, right? But as it gained more and more attention, I realised it must be a movement, not just a simple idea, so I set out to discover what DevOps was really about.

This blog is my summary of what I’ve learned from reading about DevOps over the last few months. There are heaps of resources and lots of people making great observations, so what I’ve done is try to distil lots of salient points into bullet-point format to make it easy for people to pick up as much as possible in a short read. Continue reading

Is it really a DSL, or just an expressive interface?

Clowsn with GuitarsI think the term ‘Domain Specific Language’ (DSL) is starting to become over-used and is being applied to things that aren’t really languages at all.

A Tale of Two Designers

When I think about explaining DSLs to people, the examples that spring to mind are languages like SQL, Regular Expressions, maybe even BNF, or CORBA IDL. And if I think about Why these languages exist, I imagine that somewhere, at some time, somebody thought:

I’m going to design a new language that is specifically crafted for solving this particular problem.

I like DSLs. Or maybe it would be more accurate to say I love them. They are powerful, expressive, and allow people who are eager to describe a solution or encode information (be they programmers or otherwise) to escape the complexities of imperative paradigms and Von Neumann thinking, permitting a strong focus on the actual problem.

In contrast to the above, the way in which I’ve most frequently seen the term DSL used of late is from people thinking something more like this: Continue reading

Graham’s Guide to Learning Scala

From The Archives: This article is one of the all-time most popular posts from my previous blog Graham Hacking Scala. I thought it worth updating and re-printing it here.


It’s a pretty widely-accepted view that, as a programmer, learning new languages is a Good Idea™ . Most people with more than one language under their belt would say that learning new languages broadens your mind in ways that will positively affect the way you work, even if you never use that language again.

With the Christmas holidays coming up and many people likely to take some time off work, this end of the year presents a great opportunity to take some time out from your week-to-week programming grind and do some learning.

With that in mind, I present “Graham’s Guide to Learning Scala”. There are many, many resources on the web for learning about Scala. In fact, I think there’s probably too many! It would be quite easy to start in the wrong place and quickly get discouraged.

So this is not yet another resource to add to the pile. Rather, this is a guided course through what I believe are some of the best resources for learning Scala, and in an order that I think will help a complete newbie pick it up quickly but without feeling overwhelmed.

And, best of all, it has 9 Steps!

Continue reading