Matt Kimber

teams

Performance Reviews

I had an interesting conversation last night about that old bugbear, the annual performance review. No matter how many well-meaning attempts have been made with SMART targets or peer review systems, every annual review I've had or given during my professional career has gone something like this: * Here are a

technical debt

The Sierra Adventure Codebase

We broke something this week. Well, I broke something, if you go by code authorship. It was supposed to be a bug fix, and we did everything by the book - pair-programmed the fix, did a code review, got our testers to do some QA, even went through the don't-really-believe-in-it-but-pick-your-battles

organisations

Bias for action and agility

What has linked all of the high-performing teams and organisations I've worked for or with? That title is a bit of a clue: it's a bias for action. What this means is they believe the way to solve a problem or to improve things is to do something. A team

teams

Bad Team Leads and Responsible Adults

Does a team need a team lead? I've been thinking quite a bit about flat team structures over the past couple of weeks. As is often the case, it's recruitment-driven. I'm going to be blunt here: I've been really disappointed by the prospective tech leads I've been interviewing. This is

architecture

Avoiding growth by accretion

Software has a tendency to grow by accretion - a gradual build-up of material causing what was a small and simple nucleus to become a large, complex object with many layers. It's the same mechanism by which planets form. A small clump of particles attracts other particles, and this new

ai

What my AI learnt on its holidays

I spent a bit of downtime recently playing with LSTMs and RNNs - Long Short-Term Memories and Recurrent Neural Networks. These are the kind of things that power automatic image tagging, recognition, and generating silly names for paint colours [http://aiweirdness.com/post/160776374467/new-paint-colors-invented-by-neural-network] . As is usual for me,

career

What is a Technical Architect anyway?

I spent a fair chunk of my career being a technical architect, most of which I also spent dreading the inevitable, "so what do you do for a living?" question at parties. Mostly I settled on answering, "I don't know" and quietly sobbing in a corner, because at least that

voice

Dimming the lights on voice

For me, voice control is one of those technologies that seems to be perennially almost but not quite there yet. We've spent the last 20 years correcting the Word documents we dictated to Dragon, having our in-car Bluetooth call the wrong person, sending incomprehensible text messages with Siri and recently

terraform

Terraform - Beginner Pitfalls

After a rocky start, Terraform has become a great success story where I am. We've got both infrastructure and development teams using it, sharing both learnings and resources such as modules and code. A consequence of that is I spent quite a lot of my time helping people get started

devops Featured

DevOps: What I Learnt From A Nightmare Journey

I've just finished what was a very rough journey into a fully-automated deployment infrastructure at a large scale. At times it felt more like I was in a bizarre far-future version of a Victorian penny dreadful, complete with roguish charlatans and cliff-hanger disasters. But we battled through it all and

agile

The Definition of Done Dashboard

I've been working on an infrastructure-heavy project of late, and one of the problems our team faced was differing viewpoints on what "done" actually means. In short, we ended up with a lot of variations of the following conversation: "It's done, I finished it." "But... I still see an error

agile

Technical User Stories - Who, What and Why

One of the problems we regularly face with our more technical stories (for example, setting up a monitoring stack) is explaining to the people in charge of the budget why they should pay for this. It's a valid question. I think it arises because when we're writing technical stories, we

infrastructure

IaC and the post-environment world

For about a decade I struggled with the common problem of environments. You usually start off with some well-meaning attempt at a simple layout, with development, integration, staging and live. Which feels fine, until you realise your company has different release cycles for software and data. So you split up

agile

Too much in flight

In a Scrum context, multitasking is bad. Teams who follow Kanban will be familiar with this concept, as that process invites you to explicitly set your lane limits up front - only 3 things in progress, only 2 things awaiting product owner review, only 7 tickets waiting for release, and

architecture

Services in the Monolith

It's become accepted that microservices, when done right, are a Good Thing - helping you keep your responsibilities nicely separated, easily share functionality between applications, and scale in a granular fashion where only the hot spots are spread across a multitude of servers. It's less commonly accepted, but even more

cloud

Writing a Facebook Messenger chatbot with AWS Lambda and Terraform

There's a lot of buzz around about exposing services as chatbots. Whether that's interactive chats to help you book travel, or a simple Slack bot that lets you run a build, they're turning up everywhere. (Although as usual, nothing on the Internet is truly new: old hands will remember things

aws

Cloud, PaaS, solution size and lock-in

I have a bit of a counter-intuitive opinion on cloud services and the Platform-as-a-Service (PaaS) world. For me, something like AWS isn't about "big". Yes, I know plenty of companies use elastic scaling to run huge, demand-based infrastructures along the Netflix model. But for rest of us, we're not building

development

The state of TDD

The state of test-driven development across our industry is terrible. This may seem a rather brazen statement, given pretty much everybody and their dog is writing tests somewhere vaguely around the same point as they write code, and you don't have to scroll far down this blog to find an

development

Strict pattern adherence considered harmful

Overly strict TDD and SOLID are this generation's factory pattern and XML. If you don't know what I mean by that, open a piece of "enterprise grade" code from the early 2000s (you do have a stash of that kicking around, right?) That boilerplate-laden J2EE or .net 1.0 code

tools

Where is my NuGet API Key?

This turns out to be one of the Great Secrets of the Internet, and I wasted around half an hour scanning documentation, Googling various permutations of "NuGet API Key" and "How to find NuGet API Key" before finally finding Phil Haack's page here: http://haacked.com/archive/2011/01/12/

agile

The Backlog

I had one of those "changing the way we work" discussions today, about the product backlog. I'll spare you the details, but it came down to answering two questions: 1. How many of the stories we know about should we have on the product backlog? 2. How many of the

development

How I Code

One of the things I like about the way the tech industry has changed since I cut my first production code is that even the senior guys and girls are expected to be able to roll up their sleeves and hack some code every once in a while. I don't

planning

Planning isn't free

I've got a confession to make: I secretly enjoy rewriting code when requirements change. I get to think again about what I was doing and my assumptions, tidy up the lingering technical debt, make a few performance optimisations and abstract things a little bit so I don't have to worry

organisations

ln(t): The startup growth problem

Here's an article that I found in my backlog, and realised I never got round to publishing. When I wrote it I was thinking predominately about startups, but on reflection there's a lot of relevance to organisations of any size; particularly ones that are going through a lot of change,

organisations

Firefighting

Firefighting is one of the biggest and most common causes of lost productivity and morale in software development. It usually manifests as developers being pulled off their project to urgently fix something - the live site is spewing 500 errors, there's a button in the wrong place, or a senior