Recently Read

Like many technologists, I’m always in interested in reading articles – or listening to podcasts, or watching videos – about the software industry. I thought I’d share a few of those items that have piqued my interest recently. Not all the links are new, but hopefully you’ll find them all interesting.

 ThoughtWorks May 2015 Technology Radar

Every 6 months or so, ThoughtWorks’ Technology Advisory Board puts together a technology radar based on their experiences and opinions. While biased based on those criteria, it’s still an incredibly valuable snapshot of what’s either trending, or dropping away, in the technology sector.

The radar is split in to four quadrants (techniques, tools, platforms, and languages & frameworks), and four rings (hold, assess, trial, and adopt). The quadrant names are fairly self-explanatory, but the rings lesss so: they range from “don’t start anything new with this technology” (hold), through to strong recommendations that a given technology should be adopted (adopt). It’s important to point out that the radar is a point-in-time (and opinionated) view of what’s rising and falling; stable technologies are not included.

Neal Ford (one of the members of ThoughtWorks’ TAB) published an article called Build Your Own Technology Radar which details both how the radar is created, and why you should create your own, personal radar.


The first draft of the JSON API specification was created in May 2013 as an attempt to codify the shared expectations between ActiveModel::Serializers and Ember Data. Two years, and hundreds of pull requests later, the JSON API has reached v1.0.

This article is a deeper dive in to the history and reasoning behind the JSON API spec. One interesting point is that the creators of the spec have attempted to address the issue of backwards compatibility by implementing a policy of “never remove, only add.” In practice, this means that there will never be any changes applied to the spec which will break backwards compatibility (and there will never be a v2, from a semantic versioning perspective).

There has been additional coverage of the 1.0 milestone, and the JSON API project in general, over at ProgrammableWeb.


You can barely have a conversation with any designing software at the moment without hearing the term Microservice. Despite the currently popularity, there are many reasons why using Microservices may not be the best approach for your system, especially when you’ve yet to clearly define your domain model.

In this article, Martin Fowler discusses the benefits of building monolith-first. Working in this way can avoid the initial costs associated with Microservices, and to allow you to discover where the appropriate bounded contexts may be within your system, given that any refactoring across services is much harder than it is within a monolith.

Related: Are You Infected by Microservice Envy? – a podcast from ThoughtWorks where Scott Shaw (TW’s head of technology for Australia) describes “Microservice envy,” and the habit sufferers have a jumping in to try to build a Microservice-based platform before they’re ready to.

 O'Reilly Software Architecture Conference 2015 Videos

In March, O'Reilly ran a conference dedicated to the practice of Software Architecture. I would love to have been able to attend, but I’ll have to make do with these (mostly quite short) videos of the keynotes and some individual interviews from the event, as well as the occasional round-up blog post.

I found the headline keynote by Martin Fowler and Molly Dishman to be difficult to follow and disappointingly unengaging, primarily because the switching between the two speakers just didn’t flow well, but there are a number of other, more watchable videos. If you have a spare $700 you can buy the videos from every course, workshop, talk and interview that happened over the week.

 Refactoring — Not on the backlog!

Ron Jeffries (one of the three founders of XP) builds up a simple, yet effective, “traversing field full of weeds and thickets” metaphor to explain how technical debt accumulates, and reasons that you’re much better off approaching paying own this debt bit by bit as you encounter it, rather than “putting a story on the backlog” to deal with it later. This definitely mirrors my experience, where big refactoring sessions rarely happen and, if they do, you never seem to get as much as you’d hoped out of them.

 The First Secret of Design is … Noticing

Tony Fadell, one of the fathers of the iPod, and now of Nest Labs, discusses the process of hubituation, and how it can both help (allowing you to learn by reducing responses to regular responses) and hinder: it stops us from noticing — and fixing — the problems around us. He gives three suggestions for breaking through your habituation: look broader (take a step back from the problem), look closer (and see the tiny details), and think younger (don’t just think “that’s how it is.”) While he talks from a product background, his principles can easily be applied to myriad other areas.

 It’s The Future

To finish off, here’s a little bit of tongue-firmly-in-cheek writing about the current hype-state of software and system design and operations. Read it, laugh at it, then think about it.


Now read this

Tales of the unexpected

Sometimes things go wrong. The results of the “something” going wrong are usually fairly obvious — searches not returning, systems not starting, payments not processing — but working out why that “something” stopped working (or started... Continue →