Author Archives: Ben

Sphero 2: Not just a toy

I saw my first Sphero at Microsoft’s BUILD conference in 2013. Sphero wasn’t new at the time, but after seeing it in action I just had to have one. Who wouldn’t want a silly robotic ball that you can control with your smartphone?

Image via

Fast-forward 12 months and the revised Sphero 2 is on my desk. It’s faster, brighter and apparently more agile than the original. The 10 year-old and I had a blast putting the new Sphero through its paces, bumping down the hallway and occasionally hitting the ramps. Yup – it’s still pretty hard to get Sphero heading in the direction you want, but it sure is fun while you try.

Out of the box (which includes two jump ramps), Sphero 2 is quite a bit more fun than the original. A new career mode has been added to the basic smartphone app, encouraging users to play with Sphero to unlock new tricks and develop their control skills. There are of course a bunch of other apps to play with too.

But to me, just playing with Sphero using the provided apps is only the start.

Programming Sphero

Orbotix have obviously had a lot of feedback from people like me: coders and parents of curious 10 year olds. Their Sphero MacroLab and more advanced orbBasic apps provide a great way for kids (and adults) to experiment with basic programming techniques. I’m not sure how many institutes have taken up Orbotix’s education discount, but it looks like a great idea.

For those with more experience in coding, Orbotix provides a full Sphero SDK for most platforms, and a bunch of documentation and information via their official developer portal. Orbotix’s GitHub profile is a quick way to to see some of the available samples.

Perhaps one of the more zany things about Sphero is that you can use its location and orientation sensors as input devices, rather than just telling the robot where to go. There are a few examples of Sphero as an input device for gaming and 3D input, but perhaps the coolest one is using Sphero to control a drone:

The demo above uses the AR-Drone Sphero SDK. Perhaps you could take it to the next level by using the spheroSMS package to control the AR-Drone via Sphero via SMS?

In conclusion, Sphero is totally nuts, both as a simple toy and as a tool for education and software development. It’s just plain fun, and I can’t wait to play with the new Ollie, which promises to be like Sphero on steroids.


Those following along at home will know that I recently wrote about the place of responsibility and ownership in software development. While valid throughout software engineering, ownership is especially important in the context of a rapidly scaling software business – we need to be able to rely on developers to get things done without a massive layer of management whom we neither have the time to recruit, nor the culture to support.

The seminal Netflix culture  slide deck (yeah it’s a doozy – I’ll wait while you read it), illustrates this wonderfully as the point where the growth rate of the business out-paces the density of high-performing individuals. This is traditionally the point where layers of management and process are introduced to deal with the ensuing chaos.

First ever 747The clue to solving this is imbued throughout that Netflix deck too: trust. Without trust we can’t expect responsibility to flourish. Without trust we sit on the shoulders of developers, imposing restrictions and demanding feedback. Proponents of Agile would call this an impediment.

So what does trust look like in a rapidly growing engineering team?

Solving the right problems

Newly minted development managers coming from a technical background (and there’s an argument they should only be from a technical background), often feel to manage developers one needs to prove one’s technical prowess. I’ll admit to falling into this trap myself, especially when working with a new team. If they don’t respect me as a coder, how can I have any authority?

Here’s the thing: the problems you need to solve as a technical manager are by definition non-technical. You need to create an environment in which the engineering team can execute to their potential, and otherwise just get out of their way. The last thing you need is technical authority. I suggest you get your technical jollies forking MEAN at home, and use your fading technical knowledge when liaising with the business, but otherwise close Sublime Text or Visual Studio and walk away.

Do you trust your team to choose the right libraries, architect solutions, solve loosely-defined technical problems, and code to their best abilities? How about do you trust the team to deliver a solution that is the best mix of JFDI and polish for a given timeframe? If you don’t, then you have a problem infinitely larger than your technical abilities could ever solve.

So, what problems should you be solving in order to build responsibility and ownership in your engineering team, and build a self-propelling engine of international awesome?


Work with the business to make sure the engineering team are working on the right thing, right now. Help them understand how to build the right way. Here’s one I prepared earlier.


You are undoubtedly right to abhor a 50-page technical specification, but you do need to demand enough information so that engineers can understand the scope of the task at hand, and ensure they can connect to the right people to get the detailed answers as they build. This might be Product Management, or perhaps direct customers. Facilitate and engage, then leave them to it; don’t dictate.

You need to be a navigation buoy in the flow between engineering and their stakeholders, rather than an hourglass through which all information must travel.


Provide space and time for the team to lay their foundations. Documentation, tooling, code reviews, training, recruiting, onboarding, communication, experimentation. All of those things that are “invisible” to customers but oh so incredibly important to the smooth operation of a dev team and the production of world-class software.

You need to be the advocate for this behaviour, explaining to the business why it is essential. But trust, trust that the team can execute this foundation work themselves.


If you’re getting a lot of the above right, then your team will be a fecund swamp of talent. Engineers will be popping up and seeking out challenges. It can be super tricky to find opportunities for growth in a small team and company, but one simple way to promote growth is to delegate ownership as much as you can, because this supports the growth of both the team and the individual – things you need to be happening as the team size grows.

You can also facilitate internal presentation sessions to foster talent within the team, then support your engineers if they want to present externally.

Use your gut feel and previous technical experience to pinpoint areas for improvement and work with each engineer individually to help them improve those areas. We’ve found some benefit in plotting a modified Urban Airship Tech Ladder across four axes, which can show where an engineer perhaps excels in some areas but can improve in others. Great food for growth!

Output will flow

I imagine some readers are having heart palpitations because I haven’t mentioned delivery, or deadlines, or output. My assertion is that if you get the above right – especially focus and clarity – output will flow. Sure you can tweak the dials on time spent on foundation vs delivery work, but only for short periods of time.

Trust the team. They will deliver.

TL;DR version: Are your engineering managers solving the right problems, or are they an impediment?






It’s pretty obvious why you would pay an experienced (and skilled) software developer more than a fresh graduate. Beyond that, if you’re working for a company with a great hiring ethos, differentiating engineers by relative ability becomes murky remarkably rapidly. I remember working with a particularly gifted graduate in a large company that used a fixed 3 year pay scale for graduates, and wondering why she should be restricted to a graduate salary when she was obviously outperforming many others.

Like it or not, there is value in having a concrete way to rank software developers. It serves as a checkpoint for salary bands, and also helps developers to understand what they need to do to be “better” (aka paid more).

There are a number of pre-canned “software developer maturity models” around the place. Urban Airship published their tech ladder, which is well written and has the bonus of mapping technical roles onto equivalent management roles – this really speaks to me because I’m a huge fan of the non-managerial technical career. Jin linked me to another great article about “mature” engineers (as opposed to gifted, but inexperienced engineers), which also pushed my “nod nod” button.

I’ve had this nagging feeling that there was something missing from all of these models. It’s taken me a while to put a finger on what it is.

Making Smiles

Having spent a fair bit of time as a manager of developers, there’s one really simple sign (for me personally) that developers are growing: smiles. Those little smiles that I get when I’m hopping in my car after a day at work, or reading an email, or watching an interaction. Those little “wow, yeah, that’s the behaviour I’m looking for” moments.

It’s not that I don’t smile at other times. I love hearing about how someone used throatwhistle.js* to solve a tricky problem, or how they Capistranoed the Puppet onto the SSH. But the thing is: coders be coding. Getting better at technical tasks is simply how you do your job, not how you become a better software developer.

If I think back on those private smiles, there is one common factor behind them: responsibility. They are the moments where I’ve seen a developer moving from one level of responsibility to another. Perhaps a developer has said “hey, I’ll deal with that customer query, don’t worry about it”, or maybe they are pre-empting my thoughts by emailing another developer about an impending dependency that has an unclear delivery date. Fantastic!

These are the times when I’ve become positive that there’s one less thing I need to think about when planning that developer’s workload. One more hour of my week available to think strategically. That sounds selfish on a second reading, but bear with me for a bit.

Towards a Responsibility-based Developer Maturity Model

You may be the most incredible coder, but if you don’t take responsibility for what you are building right from design to delivery, you’re leaving holes in your work for others to deal with. It really is that simple.

This is a straw-man, but I think a responsibility-based developer maturity model is what I’m looking for. Here’s how it might look:

Code Responsibility

A freshly minted graduate understands how to code. Depending on their degree, they might know a bit about software delivery models, but even then they will take time to learn how delivery works at your company. As such, the level of responsibility you might expect from a fresh developer is limited to the code they have created. They need to be told what to build, and often how to build it, but once built they should be able to own it.

Personal Responsibility

“What should I be working on now/next” defines this level of maturity. You’ve moved away from being fed work to do, and are actively seeking out the next piece of work. For a dev manager, this is the first sign of a great developer in the making. Curiosity, drive, and work ethic are all apparent in this level of responsibility.

Functional Responsibility

“Talk to Jane about XML tax updates, she really understands that function”, or more particularly, Jane might email and say “If anyone needs to know about XML tax updates, come and see me, I’ve grokked it”. This sort of behaviour shows that a developer has come out of their shell. They’re confident in their technical ability, they have some respect in the team, and they’re now putting their hand up to take on responsibility outside of their own personal sphere.

Platform Responsibility

“Dave is the Javascript guy”. You’ve proved your technical ability, you have the respect of your peers, and you’re being asked to make decisions about libraries and tools. But it’s not just about your technical skills – your peers know that you’ll take everything into account when making platform decisions, including developer happiness, so they trust you (and in fact rely on you) to help make these decisions.

Delivery Responsibility

“You can really rely on Sally to keep you up to date on where she is at and when her team will be finished”. From a management point of view, this is the ultimate level of responsibility. Developers working at this level will rally their team, manage their time, and deliver on their promises (or let you know when they can’t). There’s really not much more I could ask for than this, because it encompasses everything – including technical ability. A developer like Sally will tell you when there are holes in the spec or a technical gap in the team.

With Great Responsibility…

Reflecting on the above, it’s interesting that responsibility maps reasonably well to respect, and respect (in developer circles) can be an approximation for seniority. Want more respect from your peers? Take more responsibility for your work. The other thing to consider is just as no one bestows respect, no one is going to just give you responsibility (in fact, you’ve probably all worked with poor managers who have been given responsibility without the requisite ability).

Care about your work, take ownership of problems and delivery, look after your team members, communicate with your customers. This is what responsibility looks like.

Does this work as a maturity model? I think we might end up with those responsibility categories mixed in with Urban Airship’s tech ladder. I’d love to hear other opinions on whether responsibility is the missing link when we think about software developer maturity.

*Someone once told me about a drinking game, where you drink if [randomNoun].js exists.


When I lack focus, I often feel like I’m doing all the right things, but getting nowhere. Swimming in a vacuum is the best way I can describe it: no amount of attention to technique or increased pace is going to make a difference if I don’t have a medium to pull against. My personal focus is my task list. I’m not perfect, but when I compare those days where I religiously tick off my prioritised tasks with the days that I drift, the difference in output is stark.

bokehLikewise, without focus a software engineering team can look and feel like they’re doing great, but not make headway. You can have all the right pieces set up just the right way, but all for naught. No amount of engineering talent, no fantastic working environment, nor great team culture can make up for a lack of focus. It’s that important.

So, you’ve got – quite literally – infinite possibilities in front of you. How do you focus? I’m still working on it, but I reckon it comes down to this: build the right thing, the right way, right now. I laugh at how simple that sounds, but so many times I’ve been caught out by how uncommon common sense is. You may too very well scoff, but let’s take a look at these things in detail.

The Right Thing

The number of paths to take can be utterly overwhelming, so how do you choose the next one? Regardless of how you choose, know this: you must choose. Without a clear priority order of problems to solve (aka engineering tasks), you doom your team to endless half-assery and direction change.

It’s ok though, you don’t have to choose once and never change, you just have to choose the next thing. The next thing is what your engineers are building right now, which could be multiple things at once if you have multiple teams. Define it and get building it (the right way, right now), then you can go back to choosing the next right thing. Even if you chose the not-quite-right thing, getting that clarity for engineers means you can move on to the next right thing rapidly, while accruing some value from a completed feature. Getting to Done is fundamental.

Deciding the right thing is specific to your project and is a real product management art, but choosing a metric will help. Rank your opportunities according to those that will move that metric the most in the shortest amount of time, and pick the top one. You’ll quickly discover if your metric is incorrect.

The Right Way

Great engineers understand the difference between technical debt and slop. Never do slop. Slop is crappy method names, 10k-line JavaScript files, and nested for-loops with SQL queries in each. Technical debt however is a considered approach to build something in a sub-perfect way. Technical debt is choosing not to build this feature to cater for all the possible future uses. Debt (technical or not) is leverage, and your engineers should understand that leverage – used wisely – grows companies.

If you don’t have automated testing, continuous integration, and push-button deploys then you’re absolutely not doing it the right way.

The Right Way also speaks to culture. If you’re burning out, not communicating with everyone in the business, or not building the skills of others in your team, then you’re not building the right way.

Lastly, the right way means engineers understanding the problem that is being solved. Product management has a huge part to play here, defining and articulating the business opportunity represented by building the right thing. Done well, this serves as an inspiration to the engineering team, whereas a poorly defined problem leaves engineers adrift.

Right Now

Some call it “Lean”, but we call it JFDI: Just Fucking Do It. Don’t wait, don’t agonise over every nook and cranny. Make mistakes, fix them – rely on your fantastic devops and test procedures to help catch them. Deploy urgently and measure.

You’ve decided the number one priority for the business, you know how to build it, so dig in and do it right now.

Check Yoself

So, with an understanding of what lies behind the sentence, we can check on the quality of our focus by continuously asking: “am I building the right thing, the right way, right now?”.

Well, are you?




We Are Treating it Very Seriously

After reading Lance’s latest post, I remembered an interview I heard on the radio this morning. It was about a serious workplace accident, at a company that has had two recent workplace deaths. The man being interviewed said:

“We are treating this very seriously”

I’m going to come right out and say no, you are not. You are not treating this very seriously at all. Neither are Auckland Transport, the NZTA, nor countless other organisations dealing with the interaction between humans and heavy machinery.

“Treating it very seriously” is not getting on the radio to talk about treating it seriously. Treating it seriously is protecting human life and limb at any cost. That’s all there is to it. Goods, services, transport – what’s the point if we’re killing people in the process?

Shut it down and don’t open it up again until you can guarantee me that no one will die at your port.

Ban cycling from all inner city routes until you can grade-separate cyclists from traffic. Shit, in many cases (Ponsonby Road, Parnell Rise, Tamaki Drive) all you need are some portable barriers and the removal of carparks, and cyclists are now safe. At the cost of what? Some extra walking time for people having to park farther away.

And don’t you dare fucking preach about the inconvenience. Inconvenience? Go and talk to the family of a dead person about inconvenience.

We only have our lives.

Smart TV is Bullshit

Smart TV is a pile of arse. Check out this latest fucktastrophe* from LG:

“When you first turn on the TV, an animated character called Bean Bird appears to help guide you through various options.”

What the shit? LG gets WebOS, lauded as one of the most promising operating systems of recent time, and uses it to create fucking Clippy for television?

It’s ironic that after reading all these “you must create!” missives, my first long-form blog post in god knows how long is inspired by the desire to burn down the creations of others, but stick with me here: “Smart TV” needs to die in a fire.


Standard-issue CD for TV interface designers

For decades now (pretty much since the invention of the remote control), TVs have had on-screen displays, which have been getting more terrible with each passing moment. More menus, more options, more inputs: all artfully designed by some half-blind shitbird with a “250,000 Web ClipArts” CD-ROM.

And somehow, in an age with practically unlimited computing power, TV manufacturers managed to build user interfaces with the responsiveness of a rolled pork roast. What the fuck is up with that? It’s not even like there are space or heat constraints limiting the chips they can use.

All this time computers and phones have been getting more usable and more responsive. What have TV manufacturers been doing? “Why Ben,” you say, “they’ve been adding features!”

Features like an unusably slow, impossible to navigate web browser! A shitty walled-garden tick-the-box-we’ve-shipped-it-boss app store! How about this awesome streaming video service that proxies traffic through our servers in Asia?  And don’t forget Angry Birds!

Fuck. Off.

Just stop. For one second stop and make me a television that looks great, operates quickly, and gets itself the fuck out of the space between me and my video entertainment. Please.

AND: if you feel the need to create a god-damn animated character to help people understand how to set up their TV, step the fuck back and ask yourself WHY you got to that point. Look yourself in the mirror, you “Smart TV” charlatans. Go fix something that is broken for a change.


*Credit to Nat Torkington for the word “fucktastrophe”.



Here is a list of some things. Many of these have been mentioned in conversations in most forms of media about sexual activity and rape over the last couple of weeks:

  • Drunk
  • Out late at night
  • Wearing skimpy clothes
  • Age of participants
  • Up for it
  • Knew what you were getting into
  • Not brave enough to complain
  • Not a virgin
  • A virgin
  • Slutty
  • Liked the attention
  • Friendly
  • Naked
  • Got into bed with boys

Here is what is relevant when discussing rape (or unlawful sexual connection):

  • Consent.

It bothers me greatly that consent is barely (never?) mentioned in any conversation in the media. This is rape culture.


Microsoft Surface: Hardware is not the problem

Attending the NZ launch of the Microsoft Surface 2 and Surface Pro 2 yesterday was quite weird. You might know that for the last couple of years I had been heavily invested in the Microsoft platform. I literally relied on Microsoft and Windows 8 to feed my kids. Not anymore.

So I looked on dispassionately as the Microsoft people enthusiastically extolled the virtues of these second-gen tablets. Lighter! Faster! More ports! More battery! All wonderful stuff. The Surface 2 in particular is massively better than the Surface RT it replaces (and that Microsoft are strangely still selling – I’m guessing they have a shitload of inventory to run out). Where the RT was embarrassingly slow, the Surface 2 is buttery smooth. I can’t tell you how enraged we were as developers when our gorgeous apps ran like shit on ARM Win8 tablets. I’m glad Microsoft have fixed this. The latest generation of ARM Win8 tablets are all but perfect.

The Intel-based Surface Pro 2 is a beast. You can get one for $1299, but fully kitted out it will cost you closer to $2500. That high-end model is stupendous: 8GB of RAM and a 512GB SSD, it runs faster than most laptops and is still incredibly small and light. I don’t exaggerate when I say that the Surface Pro 2 is the best bit of Windows hardware anywhere. It’ll run Photoshop properly, and give you a full digitiser to use while doing it.

The new covers are great too. There’s one with an optional battery, and the keyboard covers have been greatly improved with backlighting and weight reductions.

But (there’s always a but) while hardware is certainly a problem Microsoft needed to solve, it is not the problem Microsoft currently has.

Questions to the presenters about the hardware were easily answered (“yeah this shit is awesome! It has 72 graphics cores!”), deeper questions about the platform resulted in the waffle that is the signature of a corporate employee saying “yeah we have a problem there but I’m going to pretend we don’t”.

When asked about the target markets and uptake of the previous model Surfaces, the response was “yeah we’re not sure what has been holding back uptake of the Surface Pro”. To be fair, Microsoft hasn’t had a corporate reseller channel for Surface, instead directing companies to buy from Noel Leeming or JB Hifi in NZ. This has been sorted out now, so I wonder if that will reverse the trend. But in any case I was really surprised that they admitted Surface Pro uptake has been disappointing. The $900m write-down was on the Surface RT after all, not the Pro.

When I asked about corporate apps and uptake, I got the same answers I myself was shilling a year ago. Conversations about exactly the same couple of companies testing the water, and the same prototype apps that have gone nowhere in 12 months. No big-bang stories of corporates buying Surfaces (or any other Win8 tablet) by the thousand. That’s pretty sad, especially when you consider that the New Zealand Police rolled out iPads and iPhones to all front-line staff in that same 12 months.

Can Microsoft reverse this trend? I reckon these new Surface revisions are the right tools to do that job, but I’m seriously wondering if Microsoft can ever win back that portable device mindshare it has lost to Apple and Android. Still, 12 months is a lifetime in tech, and I hope Microsoft can surprise us over the next year.


Use Your Inside Voice

There’s something about Twitter that brings out the troll in me. I’m not sure what it is, but it feels like more often than not I’m responding to public figures with ranting negativity.

To be fair, I’m often responding to examples of deep stupidity, but that doesn’t mean I have to reply likewise. It shouldn’t be surprising, but a calm open-letter to an MP (also sent directly) received a significantly more constructive response than would a ranty 140 character tweet.

I’ve had a few conversations recently, which — combined with my own unease at being “that guy” — have me trying hard to be more careful in my responses. Here are my tips on being less of a troll when responding to stuff that makes you grumpy:

Engaging Governments

With government interaction, a calm, considered approach makes a lot of sense. I imagine politicians are almost immune to shouty rants, due to their daily exposure in the house, and no doubt regular dose of crazy constituents.

One might get the impression that MPs are “listening” on twitter because we are able to interact with them so immediately, but the truth is that using the processes we already have in place for legislation will always get a better result. These include (among other things) submitting to select committees, official information requests, and of course emails and letters directly to MPs.

If you haven’t engaged in lawmaking before, it’s actually not at all daunting. All opinions are valid, and in many cases expert opinion on your particular area of expertise are appreciated. A good place to start might be Mai Chen’s recent book: The Public Law Toolbox. Email your local MP. Look into what processes are currently underway in parliament, or even adopt an MP.

Engaging Corporates

Unfortunately we don’t have the same level of mandated transparency with corporations. The good thing is that they seem to be a lot more sensitive to reasonable social media feedback. If you need to add more detail, a blog post or email to elaborate on a couple of level-headed tweets is a great idea. The key thing to remember is that there are real people with real feelings behind even the most “faceless” social media presence.

Besides, being a troll is a near-certain way to get ignored by corporate social media. Take a look at this classic (did social media even exist in 2008?!) response chart from the US Air Force. Their suggestion for obvious trolls: “Avoid responding to specific posts”.

The other approach to consider is accessing a true inside voice: can you get in touch with an acquaintance employed by the company? Can you get them to see your point of view and work as an ally to foment change? This approach works particularly well for socio-economic or policy issues (as opposed to specific issues with products or services, which you should take through the existing support channels).

So yeah, thanks Koz and Nigel. Like I tell my four year-old: I’m gonna use my inside voice more often. How about you?


The Morality of Metadata

Once upon a time a phone call was transient. Triggered by a series of clicks from a rotary dial, mechanical switches at the exchange would route your call to its destination. Perhaps Peter Dunne and Andrea Vance talked to each other on the phone, but this mechanical switchboard had no record of that happening. In that world, monitoring communications probably required physically accessing the exchange and plugging in a tape recorder. It was a Big Deal.

Today, the simple act of dialling a number results in a database entry. Visiting a website leaves a trace. Touching your access card to a door panel drops a line in a text file.

We have been living under the misguided impression that we are not being watched because the actors who would watch us are inherently law-abiding and moral. The reality is that they haven’t been watching us because it required effort.

We now see the truth: with metadata so readily accessible, it is literally easier to hand over 30 days of phone and access data than to spend time asking if the original request is valid. This is a problem: humans are lazy. No law will fix that.

Spend enough time with any volume of data, and it’s incredibly easy to become desensitized. I remember working for an insurance company, working on calculations that included a field called “expected death strain”. Each (anonymous) row showed the probability, month by month, that the insured party would not be alive. It took a long time for me to realise the importance of those numbers.

A technician in some way attached to parliament sees access and phone records every single day. Someone wants a dump from those files? No big deal, it’s just a portion of those letters numbers they see every day.

I’ve been asked a lot over the last couple of days whether the recent spate of leaks, hacks and law changes are interrelated. My initial position was that no, the changes to TICS and GCSB legislation have nothing to do with a parliamentary inquiry.

I think I was wrong.

We must demand that our metadata is treated with the same level of respect as our personal property. Anything less is immoral.