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

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

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

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

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

Back in 2009, a fine developer for Los Techies produced a set of mocked up motivational posters representing the SOLID principles . She was even kind enough to release them under a Creative Commons license. But as is the way of all things, internet rust has set in and the images have been unlinked from the original article during an archive exercise - but they live on throughout the internet! I have collected the images here - and would like to say " Thank you, River Lynn Bailey ". This is a great, amusing and educational resource for everyone.

“ May you live in interesting times ”, or so goes the ancient Chinese curse. That certainly seems to be applicable to the past few years, arguably even decades. Technology marches on apace, creating a razor sharp double-edged sword that is capable of holding governments to account, yet also capable of slicing into our personal privacy and stifling dissent. Social media has now moved on from an innocent way of staying in touch with remote friends, encouraging collaboration, tolerance and discussion, and has now been weaponised in order to influence opinions, support corrupt organisations, and manipulate the Overton Window . We now have wannabe dictators attempting to force online platforms to treat speculation and lies the same as undisputed truths. We even have leaders of hugely influential companies abdicating their social responsibility to act against bad actors, allowing their platform to be taken over by fascist and racist agendas, presumably to protect bottom line profit....

Right. I have to get this off my chest. A follow-on from my habitual coding observation in my previous article . How many people habitually write Java code like this? (Clue: I see it a lot) public class Article { private String title; private String author; private List tags; public void setTags(List tags) { this.tags = tags; } public void setAuthor(String author) { this.author = author; } public void setTitle(String title) { this.title = title; } public String getTitle() { return title; } public String getAuthor() { return author; } public List getTags() { return tags; } } Then you can create an object an use it with something like: Article article = new Article(); article.setAuthor("Cam M. Bert"); article.setTitle("French Cheeses"); article.setTags(Collections.asList("cheese", "food")); // etc etc G...