Thoughts from a Thirsty Bear

I can't quite believe I am writing this in 2026. I originally wrote  a version of this article back in 2016 , 10 years ago! But I am seeing an increasing number of teams overusing their build pipeline again.  I get it. Modern build pipelines now have a huge amount of functionality. They are now far more than simple script runners waiting for a trigger - just look at GitHub Actions, or what you can script these days in GitLab. So it is becoming far more tempting to let critical functionality drift right, and into your pipeline. Builds, publishing scripts, testing etc can all drift right. But don't let it happen! As with all late actions in software, by the time it is in the pipeline it is too late. Pipelines are shared resources, so can be delayed in running. Often the runners are slow, and take time to spin up. And perhaps most importantly,   the pipeline scripting languages are designed to tie you in to a specific vendor . What happens when your pipeline vendor goes out...

  Just a quick note in case there is any doubt whatsoever. I do not use AI - or more correctly LLMs (Large Language Models, aka stochastic parrots, text extruders, clankers etc etc... ) - of any kind on this blog.  All articles, both past and future, are written entirely by my own fair hand and input manually with my somewhat dodgy typing. They are a direct link from my Human Intelligence to the written word, sharing 30+ years of real world software engineering experience.  So all the errors are my own. 

As AI adoption continues apace, one good thing coming out of this second mass experiment of the decade (the first being Work From Home, caused by Covid) is  data . As more and more companies adopt AI in the software development workflow, they are generating huge amounts of information about its effectiveness. The folks at CircleCI are in a unique position to collect the data across millions (28 million to be precise) of delivery pipelines they host. They have published a summary of their findings  here . So what do 28 million data points tell us about using AI in software delivery? It's..."interesting". TL;DR - AI's effect on branches is noticeable. It increases throughput of branches for median teams significantly (15%), but this increase never makes it to production; they are never released. The production release branch throughput degrades by ~7% for the average team - AI adoption slows down teams by quite a lot. As expected, the AI-induced pressure of generating m...

 I noticed this throwaway comment recently: " Whenever I use AI to probe a topic I know something about, it seems to make a number of errors; by contrast, whenever I use it to explore topics I know little about, it knows so much more! " I must admit I have noticed something similar. When I am asking about something I know about, such as software, AI generated responses tend to be at best flawed, at worst plain wrong. Yet when I ask about something I genuinely know nothing about the results are compelling and I have to rein myself in. It turns out this is a named effect, observed by Michael Crichton (yes, that  Michael Crichton !). " Gell-Mann Amnesia ". He noticed that experts reading articles in their field of expertise will tend to find them full of errors, whereas reading other articles, even in the same publication, on topics outside their expertise  are believed to be credible. That is exactly what is happening with AI. When the results are critiqued by an exp...

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...

  Ah meetings. The bane of all our lives. Some are useful, others...less so. But the perception has always been that they get in the way of doing our real jobs. Yet they are a necessary evil - used well, they allow information to flow between people and allow discussion to happen. Before I go on, I should point out that no, this is not another article about how to make your meetings run better, how to write a better agenda (you  are  all creating an agenda for your meetings, aren't you?) and so on. Enough has been written about that already. What I'd like to share today is a calendar hack that I find useful to tame that most annoying and insidious habit to become widespread since we have gone online -  back to back online meetings . Since 2020, when Covid forced us into the most extensive remote working experiment ever, I have noticed a trend throughout industry to book meetings into every slot, one after another. Days like that are exhausting, and people have to dis...

As developers, we should all know how to write a good git checkin message. Done right, it makes delving into change histories delightful rather than a chore.  What's that? You have never been told how to write a good checkin message? Chris Beam's article is just the thing for you!  (Chris explains the rules far better than I could here without going off on a tangent) TL;DR: Separate subject from body with a blank line Limit the subject line to 50 characters Capitalize the subject line Do not end the subject line with a period Use the imperative mood in the subject line Wrap the body at 72 characters Use the body to explain what and why vs. how But I want to talk about Rule #2 (with a little about Rule #6 thrown in). That 50 character first line limit. Rule 2. Limit the subject line to 50 characters Back in the Dark Ages, when monitors were typically 80 characters wide, this limit made some physical sense. You didn't want to wrap commit summaries because it makes them scra...

A term that I still hear occasionally is "SDET", or "Software Development Engineer in Test". It is also known by a few other terms - Developer in Test, Test Automation Engineer and so on. Essentially it is a job role for a developer whose main responsibilities are to write automated tests and frameworks to check software. And it is a truly awful case of missing the point completely . It is a job title that indicates a fundamental systemic problem in an organisation. First, some history. Back in the Bad Old Days of the 1900s, we used to develop software using a linear waterfall style process, mostly due to a bizarre and tragic misunderstanding of a single academic paper (Royce, 1970). There was a lot of management thinking that modelled software development as a factory production line, and assumed that there were cost reductions from specialisms - someone creates a software design, someone builds that design, and someone tests what has been written. At the end, som...

  We all know tests need to be reliable (don't we?!). One of the worst things any test can do is give false results, whether consistently or intermittently. A test that passes when it should fail gives a false sense of security. A test that fails when everything is OK leads to wild goose chases trying to find the non-existent problem. This should be obvious. We call these false positive and false negative  results.  But just recently I have been thinking about  what is a false positive and a false negative?  It's obvious - until it isn't. So hopefully writing this down will clear it up in my mind, and some others. I'll add that this is my thinking right now after discussing the issue with several people - just make sure the definition inside your own company is consistent. Turns out, whether something is a positive or negative, false or otherwise, depends entirely on what signal is being detected . What is the 'positive' signal?  For testing, what is a tes...

Quick update on my post from December 2022 . I have now deleted my Twitter/X account completely.  My main reason is that the brand is now toxic, and in the thrall of the alt-right. The site now openly supports far right fascist fantasists, promoted by uncontrolled automated bots spreading disinformation and right wing propaganda.  This is not something I want to be associated with. For anyone still on there, I would suggest it is not something you should be associated with either but it is your choice to make. So that's it. Done, and good riddance. For anyone who still wants to follow my microblogging ramblings, I am  on Mastodon as  @thirstybear@agilodon.social . 

 ...and they can generate bad code far faster than any human... In case you've missed it, there's is a new buzzword going around. Artificial Intelligence, aka "AI". If you believe the hype, these clever little learning programs are the solution to everything, from creating fine art to curing cancer, to writing software. They vacuum in existing data (the 'training set'), then use this knowledge dump to decide how to solve problems they are given. " It writes code? Great! ", I can hear you say. " I can use this to write my code faster! ". Certainly this is a comment I am hearing from managers, and also inexperienced developers. Not so fast, folks... Several experienced developers, including myself, have been poking around these code generation tools to see if they live up to the hype. I can assure you they don't. I am not an AI expert, but I strongly suspect that this is a function of how these tools work. Think about it - the learning ne...

Customer feedback. We all know we need it to make sure we are delivering the right thing. But sometimes we all have trouble engaging. The customer might be busy, or disinterested, or both. So here's a little tip that might just help. Like all the best stories, this happened a long time ago in a galaxy far, far away....  We were working on a web front end and associated backend system for a client. But we were suffering from the "disengaged  customer" anti pattern. The customer would not commit to a web front end design, and help us design the look and feel needed for the application. We provided a few options over a couple of iterations to try and start the design conversation, but none connected despite our efforts. So we threw in a " smelly sock ". Something so stinky it guaranteed to get folks going " Ewwww! Get that out of here!". I seem to remember we disabled all CSS formatting.... Sure enough, we got a reaction during the regular show-and-tell s...

Bill Gates chose to open his 2013 TED talk with the words  "Everyone needs a coach" . Someone to provide feedback, and help them see how others see them. True enough - I have helped many people over the years understand themselves, how they interact with others, and how they can resolve inner conflicts and improve. For me, being an effective personal coach is one part of providing quality leadership to companies, and was one reason I went on the Barefoot coaching course a while back. But let's zoom out, and look at the next level in the software industry, specifically the delivery teams. These folks should be the powerhouse of any company, turning customer needs and ideas into reality that can be assessed for usefulness, and ultimately value (whatever that is - value can take many forms. Maybe a subject to explore another day).  However, in companies I work with I am seeing a problem with many of these powerhouses. Something that I suspect is rapidly becoming a  BIG prob...