Thoughts from a Thirsty Bear

What makes a high performing team tick? What is it that takes a team from being medium or low performing into elite performance as defined by DORA? On demand deployments, single figure bug counts, next to no downtime. Having worked in high performing teams, as well as having built a few myself over the years, I feel that I have a unique perspective on what it is that allows a team to work effectively together. The "Secret Sauce". So what's the recipe?  It's...." complicated ". But it looks a bit like this: At the top, unsurprisingly there is Technical Excellence . Team members need to be fully aware of and skilled in the various accepted best-of-breed tools and techniques that are out there. These currently include TDD, BDD, incremental design & architecture, refactoring, pairing/mobbing and so on. No excuses, these are all proven techniques that improve both quality and delivery, and should not be dropped unless there is a provable reason to. Even then ...

Do you know where your team's time goes? What are the competing priorities? Understanding this can be the first step to making sense of how a team is working together at a given time, and gives fairly heavy hints how to improve things for the better. A team's investment (time, money etc) can be broadly split into four 'pots': External Demand . User-facing features, new functionality. Internal Demand . Improvement. Kaizen. Failure Demand . This is the surprises. Often nasty, time consuming surprises. Business As Usual (BAU) . Keeping lights on. Those essential maintenance tasks that keep things ticking over. Any team that understands this, and knows how interdependent they are will generally thrive. Wait... interdependent?   Yes indeed. This is a zero sum game, and any team needs to make a conscious decision of how much of their finite budget (people, time, money) to invest in each at any given time. To make things even more interesting, a team only has direct control o...

 We are certainly living in interesting times right now. Specifically here I am talking about the rise of "Artificial Intelligence" (or, more correctly, 'Large Language Models", AKA 'LLMs') in software development. Whether you believe these tools are useful, or will lead to the demise of the human race¹, there is no doubt they are surrounded by the biggest hype cycle that anyone has seen before. There is an unprecedented (many are now saying unsustainable) amount of investment happening in this area. But any investment requires a return which means marketing and sales are working overtime to bring in new paying customers. Unfortunately as a result of these intensive sales campaigns there are companies - many of whom should know better - becoming ensnared in the unfulfilled promises being made by unscrupulous companies, and are " drinking the Kool Aid ". However, once the contracts are agreed by senior management, and the (not insignificant) bills be...

I often describe the way I remember things as "hook and loop", or a "Velcro mind". Over the years I have learned and unlearned so much as technology moves on, and this analogy goes some way to explaining how I am able to do this quite so effectively. To start, I am sure everyone is familiar with hook and loop temporary fastening. Also known by its "Velcro" eponymous trademark. The non-sticky sticky fastening can attach something, then be pulled away and refastened to something else. It is "hook and loop" because that is exactly how it works - on one side it has an array of tiny flexible hooks, and on the other, fluffy side the fabric forms lots of loops. Put the two together, and the hooks hook into the loops until pulled enough to unhook the fabric. So what's that got to do with minds and memory? Imagine learning a host of concepts. Background ideas, principles and models that apply to  broad range of related subjects. Sometimes people call ...

Test Driven Development. "TDD". Some love it, some hate it. But many studies now suggest that it is highly effective in reducing bugs (some studies suggest up to 90% of bugs can be eliminated) and improving code structure. But how does it work? Why is there such an effect from such a simple approach?  But before I start I must point out that a lot of what follows is summarising a great talk by Keith Braithwaite called " Measure for Measure: quantifying the effect of TDD " from 2008.  This is just a distillation of his somewhat mathematical analysis and conclusions, simplified, and in my own words aimed at a new audience who may have missed this particular gem. So our story starts with complexity. Cyclometric complexity to be precise. Cyclometric complexity simply explained is a measure of the number of paths through a piece of code. So it depends on the number of decision points - if, while, and switch statements etc. The more paths, the more complex the code is, an...

"A little learning is a dang'rous thing; Drink deep or taste not the Pierian spring: There shallow drafts intoxicate the brain, And drinking largely sobers us again" - from " An Essay on Criticism, Part II ", Alexander Pope Those who know me, or have read my profile online, know that I teach teams how to develop software using iterative tools and techniques. These require rewiring some of the traditional, waterfall-style thinking and approaches, and yes, they can be a culture shock. In order to warn my trainees I always go through a specific explanation with them. It kind of goes like this: Many folks expect learning to be straight line. You do a training course, or read a book for something, then you use it.  Unfortunately this is the South Park Underpants Gnomes model of learning. It leaves out the important part. Learning does not work in a straight line. It's messy. It's unpredictable. You will make mistakes. Go down blind intellectual alleys. Get co...