DEV Community: David Johnson

What Went Well: Nothing. What Could We Improve: This Meeting.

David Johnson — Wed, 18 Mar 2026 09:31:12 +0000

Picture the scene. It's Friday afternoon. The sprint is over. Someone has opened a Miro board with three columns: What went well, What didn't go well, What could we improve. People are staring at it like it owes them money. After a long pause, someone types "communication" under the third column. Someone else adds "deployment process." A third person types "communication" again, not having noticed the first one.

Forty-five minutes later, you close the meeting with a vague commitment to "talk more" and "look at the pipeline." No owner. No date. No follow-up. The action items go into a Confluence page that no one will open until the next time someone asks what the last retro produced, at which point someone will say "I think we looked at the pipeline."

This is most retrospectives. Not all of them. But most.

The retrospective is, in theory, one of the most valuable rituals in software delivery. A structured moment of collective honesty. A chance to ask what's actually happening here, and to improve as a team rather than just continue. In practice, it is often a compliance exercise dressed up as a ceremony. You do it because the process says to. And because you do it badly, it produces nothing. And because it produces nothing, people stop engaging. And because people stop engaging, it produces nothing. Round and round.

The failure isn't usually dramatic. There's no single villain. The meeting fails slowly, through accumulated habits that look reasonable in isolation.

The most common is what I'd call honesty suppression. A retro only works if people say true things. But teams are made of humans with memories and working relationships and line managers in the room. Psychological safety isn't a switch you flip, it's an environment you either build over months or don't. Ask a team that doesn't trust each other what went wrong this sprint, and they will tell you what they think is safe to say. Which is usually "communication."

Close behind that is the retrospective that confuses symptoms for causes. "The deployment took too long" is a symptom. What caused it? What broke? Was it knowledge concentrated in one person? A manual step that's never been automated because no one owns it? Symptoms are easy to identify and almost useless to act on. Causes require interrogation.

Then there's the retrospective that generates actions and buries them. Twelve items on the board, three owners, no deadlines, never reviewed. The next sprint starts and everyone is heads-down immediately, and the actions exist in a document in a folder in a space that no one has the Confluence breadcrumb for anymore. This is arguably worse than not writing anything down. At least then you have no expectation of change.

And finally, the retro that happens to the team rather than with it. A facilitator running through a template, people dutifully adding sticky notes, no real conversation, no challenge, no tension. If the meeting could be replaced by a Google Form and nobody would notice, that's a sign.

Good retrospectives don't feel like good retrospectives. They feel uncomfortable, occasionally.

Not gratuitously uncomfortable. Nobody needs conflict for its own sake. But the useful retrospective will surface something that needs to be named. A process that is quietly eating everyone's time. A decision that was made three months ago that's become a millstone. A pattern in how the team communicates under pressure. If you come out of a retro feeling exactly as you went in, nothing happened.

The facilitator matters more than the format. Whether it's Start / Stop / Continue, Four Ls, the Sailboat, or something you made up yourself - the format is scaffolding, not substance. What actually produces insight is a facilitator who asks the second question. The first question, what didn't go well?, is easy. The second one, why? what's the root of that? where does that actually come from?, is where the retro earns its keep. This is why a rotating facilitator, pulled from the team, works better than a tired Scrum Master running through a template for the fortieth consecutive sprint. Familiarity breeds shortcuts.

The other thing good retros do is respect the difference between things the team can change and things they can't. Teams waste enormous energy relitigating decisions made above their authority. That's not a retro, it's group therapy. Acknowledge it, park it, escalate it if you need to, but don't spend your one improvement meeting venting about the roadmap you had no hand in setting. Focus on the things you can actually move.

Outcomes deserve more attention than format. A retro that surfaces three real insights and produces one actionable change is worth more than a retro that generates twelve items that dissolve by the start of the next week.

An action from a retrospective should have three things: an owner, a definition of done, and a date. Not "the team will look at the CI pipeline." Someone owns it. Something specific will change. By a named sprint or date. If you can't say those three things about an item, it's not an action, it's a wish. And wishes are washy.

The actions should be reviewed at the start of the next retro, before anything else. Not as bureaucratic ritual, but because the quality of your follow-through is the only signal the team has that the retro is real. The moment people believe that actions disappear into the void, engagement drops. And once it drops, getting it back is hard.

One practice I've seen work well: cap the number of actions. Three. Possibly five if they're trivial. Not twelve. The instinct to write everything down is understandable. It feels productive, but a team can only absorb so much change per sprint. Three things, actually done, compounds beautifully. Twelve things, mostly ignored, erodes trust in the whole process.

The retrospective is a bet that your team will be better next sprint than it was last sprint. Not because the sprint was magical, but because you stopped, looked honestly at what happened, identified something specific to change, and then changed it.

That bet only pays out if you take it seriously. Not solemnly. Retros can be human and I do try to make them funny. But they must be taken seriously, in the sense that the conversation is real, the actions are real, and the follow-through is real.

Most teams don't do that. They run the meeting, fill the board, close the tab, and wonder why nothing gets better.

You know what to do instead. The hard part isn't the format. It's actually meaning it.

The Firebreak

David Johnson — Mon, 16 Mar 2026 10:57:00 +0000

Go-live day has a very specific energy. There's the final pre-launch checks. DNS propagating, smoke tests passing, someone refreshing the homepage on their phone like it might disappear if they stop looking. Then there's the moment the client says "it's live" in Slack, followed by the gif with the champagne. Everyone types "🎉" in response. You close seventeen browser tabs.

And then, almost immediately, someone opens a ticket.

It starts with the low-grade stuff. A padding issue on mobile that nobody caught in staging because the test devices were wrong. A redirect that was supposed to be a 301 but is doing something weird in Safari. A form confirmation email landing in junk because the SPF record wasn't quite right. Nothing catastrophic. Just the natural static that comes with deploying anything to the actual internet with actual users.

The instinct, in most teams, is to triage it all, close the sprint, and start the next one. There's a backlog. There are features that were descoped to hit the launch date. The client is energised and has Ideas. Momentum feels like the right thing to maintain.

This is where a lot of teams quietly make a mistake.

Foresters have a concept called a firebreak. A strip of land that's been deliberately cleared of vegetation to slow or stop the spread of a wildfire. You don't cut it during the fire. You cut it in advance, during a calm period, because you know the fire is coming and you want to contain the damage when it does.

In software, a firebreak is borrowed from the same idea. It's a short, deliberately protected period after a major release where the team stops building new things and instead deals with everything that the release exposed, deferred, or broke. Not sprint zero. Not a bug bash. A structured pause with a clear purpose: get the new thing properly stable before you start piling new weight on top of it.

The typical firebreak runs a week, sometimes two. Occasionally just three or four days is enough. The length is almost less important than the protection. It only works if the stakeholders agree that no new feature work starts during this window. That part requires a conversation before launch, not after. "After we go live, we're going to take a week to stabilise before we start the next phase" is a much easier sell than "we need to pause the roadmap because things aren't quite right." The first is professionalism. The second sounds like an apology.

What actually happens during a firebreak depends on what the launch revealed, but there are patterns.

The monitoring always needs attention. You had alerting in place, you think, but now you're watching real traffic and the dashboards look different to how they looked in staging. Error rates that seemed fine at low volume need different thresholds at scale. Slow queries that you knew about but didn't prioritise are now visibly dragging the 95th percentile. You spend time on this because fixing a performance problem you can see is significantly easier than diagnosing one in the early hours of the morning six weeks later.

The documentation that was going to be written "after launch" gets written. App passports, deployment runbooks, environment variable inventories, the things that live in someone's head because there was never a good time to get them out. There is now a good time. Use it, because that person is going to leave eventually (everyone does), and "I think James set that up" is not an operational strategy.

Accessibility issues get a proper pass. In the crush to ship, the audit findings from three weeks ago got split into "critical" and "nice to have," and the nice-to-haves are sitting in the backlog. During a firebreak you make actual progress on them rather than letting them drift. This is the right thing to do ethically. It's also the right thing to do because accessibility debt compounds in the same way technical debt does, and nobody enjoys an enforcement notice.

The team holds a proper retrospective, not the fifteen-minute end-of-sprint version but a genuine post-launch review. What worked. What nearly killed us. What we promised ourselves we'd never do again and then did anyway. These conversations are worth having while the launch is fresh and before everyone has moved on to the next thing.
The lessons that get captured in the week after a launch are significantly more honest than the ones captured a month later, when the rough edges of memory have been sanded smooth by distance.

Security gets a look. Not a full penetration test necessarily, but someone actually checking whether the production environment has hardened headers, whether debug mode is genuinely off, whether the admin endpoints are properly restricted. Launch day is not the moment for this. The firebreak is.

It's important to acknowledge that a firebreak isn't rest. The name makes it sound passive. A pause. A gap. But the work is real and it matters. The difference is that you're not building forward; you're consolidating what you have.

In forestry, a firebreak doesn't stop fires happening. It controls where they can go. It limits the damage when things go wrong. And things go wrong, in forests and in production environments, with depressing regularity.

What you're really doing during a firebreak is buying down risk before you start accumulating more of it. Every new feature you add to an unstable foundation makes the foundation harder to fix. Every week that passes without documentation is a week of institutional memory at risk. Every unresolved performance issue is a potential incident waiting for the right traffic spike to mature.

The confetti has landed. The client is happy. The team deserves a moment to breathe, and then a moment to tidy.

Do the firebreak. Cut the break before the fire, not during it.

A simple webpack setup with Bootstrap and VueJS

David Johnson — Fri, 28 Feb 2025 13:44:21 +0000

I'm sure there a hundreds of variants of these out there in the wild, but I thought I'd throw my aging hat into the ring. Or keys into the hat. What's the saying?

This is something I've boiled down to be as light as I could possibly make it, and as straightforward to work with as I could get. Although critique is always welcome. Constructive critique. Don't just wade in here, call me a muppet, and then ride off into the sunset.

I've put a link to the Github repository at the end, so you can skip past everything if you just want the raw goods.

Node version management

First thing to talk about - Node.js. I expect many of you out there working on front-end development need to switch node versions between different projects. It's a given. Of course, we need a way to manage that, and I used to use NVM.

However, the past few months I've been trying out something called FNM, or Fast Node Manager, and I really like it. It's built in Rust, and if you want to give it a go, there's a very descriptive Github repo here https://github.com/Schniz/fnm that explains how to configure it.

What's in the box?

Firstly, the packaging

This is my package.json. I'm running it in Node.js 22.14.0, and there is a .node-version file in the project that should automatically install the correct node variant if you're running FNM with --use-on-cd. (I won't explain that here, it's in the repo referenced above).

{
    "name": "frontend-build",
    "version": "1.0.0",
    "description": "Webpack build for the Bootstrap and VueJS",
    "author": "davidisnotnull",
    "license": "MIT",
    "keywords": [
      "webpack",
      "boilerplate",
      "template",
      "setup"
    ],
    "dependencies": {
      "@fortawesome/fontawesome-free": "^6.2.1",
      "@fortawesome/fontawesome-svg-core": "^6.2.1",
      "@fortawesome/free-solid-svg-icons": "^6.2.1",
      "@fortawesome/vue-fontawesome": "^3.0.2",
      "@popperjs/core": "^2.11.6",
      "axios": "^1.1.3",
      "bootstrap": "^5.2.2",
      "jquery": "^3.6.1",
      "jquery-validation": "^1.19.5",
      "jquery-validation-unobtrusive": "^4.0.0",
      "mitt": "^3.0.0",
      "vue": "^3.2.41",
      "vue-axios": "^3.5.2"
    },
    "devDependencies": {
      "@babel/core": "^7.21.0",
      "@babel/preset-env": "^7.19.4",
      "assets-webpack-plugin": "^7.1.1",
      "autoprefixer": "^10.4.12",
      "babel-loader": "^8.2.5",
      "clean-webpack-plugin": "^4.0.0",
      "css-loader": "^6.7.1",
      "file-loader": "^6.2.0",
      "mini-css-extract-plugin": "^2.7.5",
      "postcss-loader": "^7.0.1",
      "sass": "^1.55.0",
      "sass-loader": "^13.1.0",
      "style-loader": "^3.3.1",
      "url-loader": "^4.1.1",
      "vue-loader": "^17.0.0",
      "webpack": "^5.78.0",
      "webpack-bundle-analyzer": "^4.6.1",
      "webpack-cli": "^4.10.0",
      "webpack-merge": "^5.8.0"
    },
    "engines": {
      "node": ">=22"
    },
    "scripts": {
      "build": "webpack --config ./configuration/webpack.dev.config.js --mode=development",
      "watch": "webpack --config ./configuration/webpack.dev.config.js --mode=development --watch",
      "bundle": "npm install && npm run watch",
      "production": "webpack --config ./configuration/webpack.production.config.js --mode=production",
      "stats": "webpack --config ./configuration/webpack.production.config.js --mode=production --json > dist/stats.json && webpack-bundle-analyzer dist/stats.json"
    }
  }

There's a dev and production version of the build. That's kind of self-explanatory, but use dev when you're dev'ing so you can debug things easier.

Enter webpack

I've used webpack-merge so that I can create config variants for development and production. You'll see these in the configuration folder in the repo.

The main bare-bones webpack config looks like this:

const path = require('path');
const environment = require('./configuration/environment');
const webpack = require('webpack')
const AssetsPlugin = require('assets-webpack-plugin');
const { CleanWebpackPlugin } = require('clean-webpack-plugin');
const { VueLoaderPlugin } = require('vue-loader')
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = {
    entry: [
        path.resolve(__dirname, 'js/app.js'),
        path.resolve(__dirname, 'scss/app.scss')
    ],    
    module: {
        rules: [
            {
                test: /\.(js|jsx)$/,
                exclude: /node_modules/,
                use: [
                    'babel-loader'
                ]
            },
            {
                test: /\.css$/,
                use: [
                  {
                    loader: 'style-loader',
                  },
                  {
                    loader: 'css-loader',
                  },
                ],
              },
            {
                test: /\.(scss)$/,
                use: [
                    MiniCssExtractPlugin.loader,
                    {
                        loader: "css-loader",
                    },
                    {
                        loader: 'postcss-loader',
                        options: {
                            postcssOptions: {
                                plugins: function () {
                                    return [
                                        require('autoprefixer')
                                    ];
                                }
                            }
                        }
                    },
                    {
                        loader: 'sass-loader'
                    },
                ]
            },
            {
                test: /\.vue$/,
                loader: 'vue-loader'
            },
            {
                test: /\.(woff(2)?|ttf|eot|svg)(\?v=\d+\.\d+\.\d+)?$/,
                use: [
                  {
                    loader: 'file-loader',
                    options: {
                      name: '[name].[ext]',
                      outputPath: 'fonts/'
                    }
                  }
                ]
              }
        ]
    },
    output: {
        filename: 'js/[name].[contenthash].js',
        path: environment.paths.output,
        publicPath: '/dist/'
    },
    plugins: [
        new webpack.ProvidePlugin({
            $: 'jquery',
            jQuery: 'jquery',
        }),
        new CleanWebpackPlugin({
            verbose: true,
            cleanOnceBeforeBuildPatterns: ['**/*', '!stats.json'],
        }),
        new MiniCssExtractPlugin({
            filename: "css/[name].[contenthash].css",
        }),
        new VueLoaderPlugin(),
        new AssetsPlugin({
            filename: 'webpack.assets.json',
            path: environment.paths.output,
            prettyPrint: true,
        }),
    ],
    optimization: {
        minimize: false,
    },
    resolve: {
        fallback: {
            "fs": false
        },
        extensions: ['.js', '.jsx', '.json', '.css', '.scss'],
        modules: [
            path.resolve(__dirname, 'node_modules'),
        ]
    }
}

This includes a compiler for Vuejs as well, as I've been using that for some simple interactive functionality. I like React, but I find it a bit too heavy for a lot of the simpler stuff that clients tend to ask for. Unless someone wants an SPA, I find myself leaning into Vue a lot more.

The great babel fish

I've got babel configured to only target modern browsers. No IE11 fixes required these days. I am so glad that old Trident engine is dead.

module.exports = {
    presets: [
      [
        "@babel/preset-env",
        {
          // Target modern browsers (>0.25% market share and not obsolete)
          targets: ">0.25%, not dead",
          // Enables polyfill injection based on your code usage (and your browser targets)
          useBuiltIns: "usage",
          corejs: "3.28",
          // Apply bug fixes from Babel's plugin layer
          bugfixes: true
        }
      ]
    ]
  };

Scripting and styling

There's an app.js and an app.scss file in their respective folders in the repo. These, again, are barebones and just import the components that you need to get going.

Extend these as you need to.

That's pretty much it. PostCSS and Sass Linting are both light-touch configured, so you've got scope to modify those as you like as well.

Now go grab the repo

I've structured all of this into a public repo on Github. Please use it to your heart's content. Fork it. Recommend changes.

https://github.com/davidisnotnull/webpack-build-framework

David

How To Add Swap Space on Ubuntu 22.04

David Johnson — Thu, 23 Jan 2025 21:35:17 +0000

One way to guard against out-of-memory errors in applications is to add some swap space to your server. In this guide, we will cover how to add a swap file to an Ubuntu 22.04 server.

Swap is a portion of hard drive storage that has been set aside for the operating system to temporarily store data that it can no longer hold in RAM. This lets you increase the amount of information that your server can keep in its working memory, with some caveats. The swap space on the hard drive will be used mainly when there is no longer sufficient space in RAM to hold in-use application data.

The information written to disk will be significantly slower than information kept in RAM, but the operating system will prefer to keep running application data in memory and use swap for the older data. Overall, having swap space as a fallback for when your system’s RAM is depleted can be a good safety net against out-of-memory exceptions on systems with non-SSD storage available.

We can see if the system has any configured swap by typing:

sudo swapon --show

If it has one, we're going to want to get rid of it and create a new one. You can do that with the following command:

sudo swapoff -v /swapfile

And then remove the file

sudo rm /swapfile

Now we want to create a new swap file. We'll set the size parameter to 8G as we want to use some VMware in Ubuntu

sudo fallocate -l 8G /swapfile

Make the file only accessible to root by typing:

sudo chmod 600 /swapfile

We can now mark the file as swap space by typing:

sudo mkswap /swapfile

After marking the file, we can enable the swap file, allowing our system to start using it:

sudo swapon /swapfile

Our recent changes have enabled the swap file for the current session. However, if we reboot, the server will not retain the swap settings automatically. We can change this by adding the swap file to our /etc/fstab file.

Back up the /etc/fstab file in case anything goes wrong:

sudo cp /etc/fstab /etc/fstab.bak

Add the swap file information to the end of your /etc/fstab file by typing:

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

There are a few options that you can configure that will have an impact on your system’s performance when dealing with swap.

The swappiness parameter configures how often your system swaps data out of RAM to the swap space. This is a value between 0 and 100 that represents a percentage.

With values close to zero, the kernel will not swap data to the disk unless absolutely necessary. Remember, interactions with the swap file are “expensive” in that they take a lot longer than interactions with RAM and they can cause a significant reduction in performance. Telling the system not to rely on the swap much will generally make your system faster.

Values that are closer to 100 will try to put more data into swap in an effort to keep more RAM space free. Depending on your applications’ memory profile or what you are using your server for, this might be better in some cases.

We can see the current swappiness value by typing:

cat /proc/sys/vm/swappiness

For a Desktop, a swappiness setting of 60 is not a bad value. For a server, you might want to move it closer to 0.

We can set the swappiness to a different value by using the sysctl command.

For instance, to set the swappiness to 10, we could type:

sudo sysctl vm.swappiness=10

This setting will persist until the next reboot. We can set this value automatically at restart by adding the line to our /etc/sysctl.conf file:

sudo nano /etc/sysctl.conf

At the bottom, you can add vm.swappiness=10. Save and close the file when you are finished (in nano, press Ctrl+x and it will prompt you to save before exiting).

Another related value that you might want to modify is the vfs_cache_pressure. This setting configures how much the system will choose to cache inode and dentry information over other data.

Basically, this is access data about the filesystem. This is generally very costly to look up and very frequently requested, so it’s an excellent thing for your system to cache. You can see the current value by querying the proc filesystem again:

cat /proc/sys/vm/vfs_cache_pressure

As it is currently configured (100), our system removes inode information from the cache too quickly. We can set this to a more conservative setting like 50 by typing:

sudo sysctl vm.vfs_cache_pressure=50

Again, this is only valid for our current session. We can change that by adding it to our configuration file like we did with our swappiness setting:

sudo nano /etc/sysctl.conf

At the bottom, add the line that specifies your new value:

vm.vfs_cache_pressure=50

Save and close the file when you are finished.

Is Threads still a thing?

David Johnson — Tue, 06 Feb 2024 21:03:35 +0000

And how many people are actually using it?

I have never considered using Threads for any kind of social marketing. Out of Meta’s products, I’m pushing content to Facebook, Instagram, and WhatsApp, but something about Threads has always put me off.

Curious, I decided to do some research to see if my gut instinct about Threads was correct.

The rapid decline of Threads

At it’s peak at launch in July 2023, Threads saw 100 million sign-ups in 5 days, the fastest app to ever achieve this milestone. On July 7th 2023, Meta reported 49.3 million daily active users.

As of January 2024, a mere 6 months later, the estimated DAU (daily active users) was around 10.3 million (that’s a 79% decrease). User engagement also decreased significantly, with the average daily time spent on the app dropping from 21 minutes to just 3 minutes.

So what happened here? Why did it see the biggest sign up rate in the history of apps, and within 6 months such a significant decline in interest? It’s backed by Meta, and Meta may be a lot of things, but they’re more than experienced in the social media arena.

The first question that springs to my mind is “do users want yet another ephemeral messaging app?”. I certainly don’t, but I likely don’t fall into the list of personas that Meta had in mind (being a 40-something year old software engineer).

However, I think it is important to note that Threads doesn’t really offer anything that you won’t find on other, more established platforms. So what’s the unique value proposition?

My research highlights that there may have been potential privacy concerns. Having to sign up with an Instagram account may have left users wary of data sharing across platforms. Additionally, the ephemeral nature of messages left users unsure about data retention and control.

Threads also felt distinctly lacking in features. There’s an absence of diverse content categories, focusing mainly on close friends and personal updates. Something that can be fulfilled by pretty much any other flavour of social app on the market right now.

There’s also a complete vacuum of news, political discussions, or broader community engagement, limiting its appeal to many users. For me, it makes the ecosystem feel quiet. Posting on there felt more like shouting into a cave than interacting with a social app. It’s got the distinct feel of an echo chamber, not helped by the substantially low number of users compared to it’s competitors.

Timing wise, I’m not convinced that Meta really hit the nail on the head with their design for Threads either, and this is surprising considering their wealth of understanding of social media.

The growing popularity of short-form video platforms like TikTok and, to some extent, Instagram, offered a more engaging and dynamic experience compared to Threads’ photo-sharing focus. It’s as though they’ve taken a step backwards and created a lightweight version of Instagram with the look and feel of X (formerly Twitter).

Many celebrities and influencers initially joined Threads, but quickly migrated back to established platforms with larger user bases and wider reach once they realised that they just weren’t getting the same level of engagement. Why waste energy on a platform that isn’t offering you any noticeable returns?

Without influencers on the platform, that’s one less thing to capture user attention. If you combine that with a total absence of news and community content, it’s no surprise that users abandoned it in their droves.

I also get the impression that Meta really aren’t giving it any love. Their primary attention seemed to be on developing Instagram and integrating features similar to Threads within it. Raising, again, the question — what was the point of releasing Threads in the first place?

Maybe they were anticipating that X would fail after Elon Musk bought it in April 2022, and that it’s user base would migrate onto Threads in the aftermath? This is the only purpose for it that I can think of. It would certainly explain the similarities, in both functionality and interface.

Enough of my esoteric musings on the matter, let’s look at some actual data and compare how Threads looks against it’s competitors.

Comparison of Threads’ user base with other social media platforms

Platform	Monthly Active Users (MAU)	Daily Active Users (DAU)	Average Age	Dominant User Group	Key Features	Strengths	Weaknesses
Threads	100M (peak, July 2023)	10.3M (Jan 2024)	18-25	Gen Z	Ephemeral messaging, close friends focus	Fast initial growth, Meta integration	High user decline, limited features, privacy concerns
X (Formerly Twitter)	253M	166M	34-49	Diverse	Microblogging, news, real-time updates	Large user base, established platform	Competition, toxicity concerns, recent user loss
Instagram	2 billion	1.4 billion	25-34	Diverse	Photo & video sharing, Stories, Reels	Large user base, diverse content, influencer marketing	Algorithm-driven feed, privacy concerns, pressure to curate
Facebook	2.91 billion	1.9 billion	35-44	Diverse	News, connecting with friends & family, groups	Largest user base, mature platform	Declining younger users, privacy concerns, information overload
TikTok	1.5 billion	1 billion	16-24	Gen Z	Short-form videos, diverse content, viral trends	Engaging format, large Gen Z audience	Data privacy concerns, potential addiction issues

Notes on the above data

User base numbers are estimates and can vary depending on source.
Threads’ user base is significantly smaller than all other listed platforms.
Whilst similar in platform formats, Threads focuses on close friends and ephemeral messaging, while X offers a wider range of content and real-time updates.
Instagram offers more diverse content and influencer marketing opportunities, but with potential downsides like curated feeds and privacy concerns.
Facebook has the largest user base but struggles with declining younger users and privacy concerns.
TikTok caters to Gen Z with its engaging short-form video format, but raises data privacy concerns.

What’s in store for the future of Threads?

It’s a real challenge to try and discern the fate of Threads in the long run. On the one hand, it holds the record for the fastest user sign up in history. It’s also seen a mass exodus of those users with the fraction that remain spending a mere 3 minutes a day on the platform.

Personally, I’d give it a “do-not-resuscitate” order and call it a day. However, in the spirit of balance, and because I can’t foresee the outcome, let’s take a look at both the optimistic and pessimistic result.

Optimistically…

Meta invests in significant feature additions, introducing unique functionalities beyond ephemeral messaging, like group chats, live streaming, or integration with other platforms.
Meta incentivizes and retains high-profile users who actively engage with the platform, driving discoverability and user growth.
Threads carves out a niche as a platform for specific user groups or interests, creating a dedicated and engaged community.
It expands beyond close friends, allowing broader content categories like news, entertainment, or creator tools, attracting a wider user base.

Pessimistically…

Meta continues focusing resources on developing Instagram and other core platforms, leaving Threads neglected and under-maintained, resulting in:
A lack of significant updates and feature additions lead to user boredom and migration to other platforms.
New or existing platforms offer more engaging features and experiences, attracting users away from Threads.
Meta decides Threads isn’t strategically important and either sells it or shuts it down altogether.

In conclusion

Threads’ future depends on Meta’s commitment to development, addressing user concerns, and differentiating itself from competitors. It needs to adapt, innovate, and capture the attention of users in a dynamic and competitive environment.

If Meta doesn’t take action on this, I can’t help but see the fate of Threads being they quietly switch it off without anyone really noticing.

I am leaning on the pessimistic side of the outcomes, and certainly won’t be recommending it as a subject of consideration for my clients. Maybe Meta will pull it out of the bag and turn it into something worthwhile. Or maybe it’ll fade away without fanfare and be forgotten as quickly as it arrived.

A decade of using git has taught me to keep a tidy house

David Johnson — Tue, 09 May 2023 22:48:14 +0000

My strategy to help look after your git

If you’re in the world of software development, then you’ll likely have come across this thing called “source control”.

I’m not going to delve into too much detail on what source control is, that’s not why you’re here. This is about my experience using one type of source control called git (as you can probably guess from the title).

I wrote this after one of my tenures as a Tech Lead in a digital agency. I was weary of seeing the word “fix” as the commit message, of having almost a hundred branches in some repositories, and being completely unable of working out what features or fixes had been included as part of a commit.

I’m putting the strategy below in the hope that it may help others who find themselves in a similar boat.

So Ctrl+C, Ctrl+V to your heart’s content.

Git Strategy

Wherever possible, these guidelines will include a specific justification for each strategy choice. Unjustified guidelines must be either justified or removed.

Whereas these styles draw mostly from the experience of the author, it also includes ideas from Vincent Dresden.

Fixing problems in this branching strategy

Unless otherwise stated, this branching strategy is not optional, nor is it up for interpretation.

If a guideline is not sufficiently clear, recommend a clearer formulation
If you don’t like a guideline, try to get it changed or removed; don’t just ignore it. Others might not be aware that you are special and not subject to the same rules as everyone else

Branching

Main Branches

At the base of our branching strategy are two evergreen branches —main, and _deve_lop.

Main, as the name suggests, is our stable branch, and reflects the latest delivered development changes that currently exist in the wild on our production environment. It should not be interacted with in our day-to-day development.

Develop should always represent the code that is being worked on, ready for the next release. It’s from this branch that we should be creating our feature and release candidate branches.

Both of these branches must be locked so that force pushes cannot be made to them (cue star wars pun), and standard pushes can only be made via approved pull requests.

Release Candidates

These branches contain code that has passed testing and is ready to be rolled out in the next release.

Release branches should be named release/

Where the release-identifier will be the name that we’ve given to this release in whatever task management tool we’re using.

As soon as the release candidate is ready to deploy to production, we raise a pull request to merge the release candidate into the main branch.

Feature Branches

A feature branch comes under the guise of Supporting Branches. These are used to allow for parallel development and to make tracking features easier.

Feature branches should be named feature/

Often, we will find ourselves using some sort of task management software, such as Jira. In this case, we need to be naming our feature branches with the identifier of the ticket, followed by a brief description of the what the feature contains. An example could be feature/DSB-545-marketing-preferences-service.

Highlander’s Law

If you’re old enough to remember that film with Christopher Lambert and Sean Connery, then you’ll probably guess what this is going to be…

There can be only one

Clearly, we aren’t lopping people’s heads off to cure ourselves of immortality. In this context, Highlander’s Law means that there should only ever be one feature branch for a particular story.

Never should we see two feature branches created by developers for the same feature. Not only is it deeply confusing for the poor bastard who has to put together a release candidate, but it’s really shoddy practise. One feature branch per feature please.

Hotfix Branches

A hotfix branch is branched from main, and should only be used to fix issues that are found in production. Due to the priority nature of hotfixes, they fall outside of the usual release cycle.

Hotfix branches should be named hotfix/

Once the code in a hotfix branch has been tested and verified, then we raise a pull request to merge the code into the main branch and release to production.

Managing code push/pulls

Fetch before you push

If someone else has been working on the same feature or hotfix branch as the one you’re about to push, make sure you do a fetch to ensure that you’re local copy is in line with what’s out there on the remote.

You can also turbo charge this process by doing some pruning at the same time:

git fetch origin --prune

Rebase, don’t merge

If you’ve checked out a branch and, after doing a fetch, noticed that your local branch is a few commits behind what’s in the remote, don’t merge the remote into your local - rebase it. That way, you’re guaranteed to get a clean copy of what’s on the remote, including the commit history.

Pushing code

This one is simple:

NEVER push broken code to the remote repo

No one wants to fix your borked attempt at software development, so don’t do it. If it’s broken, it stays in local until you’ve fixed it.

Branch Retention

In order to keep the number of branches down to a minimum, it is important to do a little bit of housekeeping after each release to get rid of anything that’s no longer needed. This we call pruning.

Trust me, there’s nothing worse than opening a repository to see it has a hundred branches. Most of which are stale or no longer relevant.

Pruning

After each release, we must perform a branch pruning exercise. The rules of branch pruning are as follows:

If the release candidate branch is greater than 2 releases ago, then we need to delete it
If a feature branch has been merged into the current release branch, and it is 0 commits in front of develop, then we need to delete it
If we have merged a hotfix branch into master and it has been deployed to live after testing, then we need to delete the hotfix branch

Boglin Branches

If you grew up in the eighties or early nineties, you might remember something called a Boglin. It was like a gremlin, but lived in a swamp.

Boglin branches are those that are greater than 60 days old and are any number of commits in front of develop.

They also live in a swamp, of stale code. We have to ask ourselves, if a code change is greater than 60 days old, do we still need it? If we do need it, can we bring it into the upcoming release candidate?

If we don’t need it, prune it.

If we do need it, then there are two questions that need to be asked:

Why was it left idle for so long?
Can we get it tested and potentially bug fixed in time within the current sprint or release cycle?

Commit Messages

A well crafted git commit message is the best way to convey the context of a change to other developers, and your future self. Be kind to your future self, and adhere to the following rules for commit messages.

As an aside, I’m sick of seeing the word fix as a commit message. Stop it.

The rules of commit messages

Separate the subject from the body

Referring to the git commit manual:

Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, Git-format-patch(1) turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body.

Proper casing on a commit message

I don’t think I need to explain any more than the heading for this section — make sure you capitalise the first word on the subject of the git commit, e.g.

Resolve merge conflicts from branch hotfix/BUG-1448

Do not end the subject line with a period

Trailing punctuation is not necessary on commit messages. Remember, space is precious when we are trying to keep within a 50 character limit.

Use the imperative mood in the subject line

Imperative mood simply means “spoken or written as if giving a command or instruction”. For example:

Tidy your room
Take out the bins
Do your laundry

Being British, we don’t like being outwardly direct or impolite. It’s perfect for commit subject lines, however. One reason for this is that git uses the imperative whenever it creates a git commit on your behalf, and computers aren’t renowned for their politeness (in some cases, neither are developers).

For example, whenever we do a merge using the git command line, we get:

Merging branch ‘feature/FEA-1234-new-navigation’

When you write in the imperative, all you’re doing is following git’s inbuilt conventions. The following are poor examples of subject messages:

Fixed bug with X
More fixes for broken stuff
Sexy new API methods
Changing structure of Y

No. This is what we call writing in the indicative mood. Being indicative is all about reporting facts, which is not what a commit subject should be — as counterintuitive as that sounds.

A properly formed git commit subject line should always be able to complete the following sentence:

If applied, this commit will [your git subject line here]

The following are good examples of commit subject lines:

If applied, this commit will remove deprecated methods
If applied, this commit will resolve merge conflicts
If applied, this commit will merge pull request #101 from feature/branch

You can see how our first few commit messages won’t work in the above format:

If applied, this commit will fixed bug with X
If applied, this commit will more fixes for broken stuff
If applied, this commit will sexy new API methods

Use the body to explain “what and why” versus “how”

When we’re looking at commit messages, we aren’t interested so much in how the change has been made, but the reasons for making the change.#

Here’s an example of a what I would deem a good commit body message:

Add CPU arch filter scheduler support

In a mixed environment of running different CPU architectures,

one would not want to run an ARM instance on a X86_64 host and

vice versa.

This scheduler filter option will prevent instances running

on a host that it is not intended for.

The libvirt driver queries the guest capabilities of the

host and stores the guest arches in the permitted_instances_types

list in the cpu_info dict of the host.

The Xen equivalent will be done later in another commit.

The arch filter will compare the instance arch against

the permitted_instances_types of a host

and filter out invalid hosts.

Also adds ARM as a valid arch to the filter.

The ArchFilter is not turned on by default.

Tagging Commits

When the code in a particular commit is released to either a test or production environment, we need to tag it. Otherwise, it’s easy to lose track of what code is sitting on what server.

My recommendation for this is to use the environment name, followed by a hyphen, followed by the date of the release in YYYYmmdd format. For example, this tag:

production-20230421

Indicates that the code for this commit is on production, and was deployed on 21st April 2023.

My journey in Midjourney

David Johnson — Wed, 03 May 2023 09:37:33 +0000

I've been messing around with Midjourney for a couple of months now. I use the phrase "messing around" because that's exactly what the process has felt like.

If you've not come across it yet, Midjourney is an AI-powered image generation tool that allows users to create images by providing text and/or image prompts. You use it via installing the Midjourney bot to your Discord, and adding the bot to your text channel.

My initial testing came out of a curiosity to determine whether I could use Midjourney as a replacement for traditional stock photography in website content or social media posts.

Just for fun, and the purposes of this article, I went back to one of the first upscaled images I created.

/imagine Cats wearing bow ties with a starry night sky

This one I kept for nostalgia. And because cats.

Getting to grips with the descriptive prompts for Midjourney has been an adventure in itself. I've had some rather horrific failures:

Do we remember the "woman laughing at salad" thing from a while back?

The general structure of a prompt is

{image prompt} {description} {parameters}

Where

image prompt would be the URL of an image that you want to use as a base, although this isn't mandatory.
description being your description of the image that you'd like it to generate.
parameters being the settings that you can add to affect how Midjourney creates the image. I won't dive into these in much detail here, but you can see what's available in the Midjourney documentation.

My one piece of advice when it comes to creating the prompts is to experiment. A lot. Try all sorts of different combinations, and don't be shy in getting Midjourney to regenerate the image set that it gives you if it's coming up a bit twisted. Of course, the more random you get with your descriptions, the crazier the results are going to end up.

Here are my thoughts on what you can consider when writing your own prompts:

Be clear in your language. The more straightforward and direct you are with your description, the better that the software is going to understand you're requirements. Don't talk to it in the style of Jane Austen or Russell Brand, essentially.
Be specific. The more detail you add to your prompt, the more it's going to match your expectations. Mention colours, objects, the environment. You've got to give it as much guidance as you can.
Talk about the mood. If you want your image to be of a certain style, then add that into your prompt. For example (and this is one of my favourites) a futuristic cityscape with neon lights creating a cyberpunk atmosphere.
Composition. Like any good photographer, you're going to have to think about the composition of your image. You can add things like using the rule of thirds or wide angle shot to your prompt to help guide the software in creating your perfect image.
Set your focal point. Again, think like a photographer. What's the focus of your image? Try to define your primary subject in your prompt.

I've actually found, after some considerable messing about, that Midjourney is a great tool for creating images for social posts (particularly Twitter and Instagram). You can adjust the aspect ratio of the images as well, which is a definite plus when posting to different platforms.

By default, Midjourney gives you a 1:1 aspect ratio. You can change this by adding the --aspect 3:2 parameter at the end of your prompt (or whatever ratio that you want to use, I've just added 3:2 here as an example).

Now, let's fast-forward rather rapidly to yesterday evening. I feel like I've satisfied the question "can Midjourney be used to create content for web". So I decided to change it up a bit. I took some stills from one of my favourite films and used them as prompts to create variations in Midjourney v5. The results are astounding.

Here's my first image prompt:

Yeah, that's Rick Deckard setting up the Voight-Kampff before he questions Rachel in Tyrell's tower (guessed what the film is yet?).

Using /imagine with the image as a prompt, a brief description, and the parameters for setting the version and image weight (at the time of writing, Midjourney uses version 4 by default, so we have to explicitly tell it to use version 5).

/imagine [imageurl] voight-kampf, blade runner --version 5 --iw 2

The result was this beauty:

And of course, what kind of fan would I be if I didn't try to recreate this iconic scene...

I'll continue experimenting with what Midjourney v5 can do. So far, I am more than impressed. Maybe another article on this in a month or two where I share my new findings.

Running fixed-price projects in Agile

David Johnson — Mon, 04 Jan 2021 18:05:31 +0000

It’s easy to default back to a waterfall way of thinking when we’re running fixed-priced projects. As a business delivering a digital project, we need to capture the entire scope of the application to protect ourselves from scope creep later on. Because scope creep in a fixed-price project can get expensive, with a capital E.

So, we start off doing our discovery work. Talking with the client. Investigating the systems that we need to extend or interface with, and reading any documentation that the client can provide us. Once we’ve done our discovery and got an understanding for what it is that the client wants us to build, we put together a software architecture document that we can present to the client and use as our statement of work. Right?

Wrong.

Let’s take a step back for a moment and think about the all important word in the title of this article - Agile. We may not be running a strictly Agile project, but we still need to be working inside the processes and frameworks that Agile teaches us as software developers.

The first problem arises when we give a software architecture document to developers and expect them to use it to build out the features of our product. For us “older” developers who were around before Agile was a big deal, it might be ok. But a lot of developers who have grown up in Agile won’t be familiar with this - they’ll be used to planning sessions and tickets in Jira with acceptance criteria that they need to work towards.

You’ve also got the issue that, as requirements change during the project’s lifetime (and they will) or new information comes to light, you’ll need to go back and update your document, then distribute a new version to the rest of the team, highlighting the elements that have changed.

I understand completely that we need to have something to provide to clients that outlines what we’re going to be building, and how we’re going to do it, but that doesn’t mean that the initial starting point should be a software architecture document.

If you have a development team, chances are you’ll be using some sort of board and ticket system to handle your feature delivery, be that Jira, Azure Devops, or something like Basecamp. So, why not leverage that to scope out your fixed price project before putting a statement of work together?

There’ll be no difference when mapping out requirements in a fixed-priced or agile project. We still need User Stories, and the subsequent tasks that come out of this. My advice is start building your features in your board before you put together the statement of work. Involve your development team in the scoping out of these tickets as part of the discovery process (think of it as a longer sprint planning session). Get the input of the people who are going to be building the application - the more eyes on the scope at this stage of the game, the better prepared you’ll be when it comes to reducing risk later down the line.

Your boards should always be your single source of truth on a project. If we have all of our stories broken down on the board, instead of tied up in an often unwieldy software architecture document, then when we get changes to requirements or new information come up later on, we can update the tickets with comments and attach the relevant documentation. This way, everyone knows where they stand.

That’s not to say that you shouldn’t have a written statement of work - you need one to outline what you’re going to contractually provide. What I’m saying here is that it shouldn’t be the main source from which you’re working as you develop your application.

Waterfall has gone out of fashion for a reason. If you’ve worked in it, particularly back in the late 90s or early 2000s, you’ll know why. It’s acceptable to use when your project is short, and when the application that you’re building isn’t overly complex. Yet you’re left running all of your tests at the end of the project, clients can’t really see anything whilst you're in the build stage, and you need to add in a lot of contingency to your timescales.

The one thing I will say is that we should never confuse “fixed-price” with “waterfall”. You’ll have to follow a similar agenda, but we shouldn’t fall back to heavy documents and rigid phasing that are akin with the waterfall model.

What you’ll need to ensure is that you have allocated a sufficient amount of time and resources into the discovery phase, because you’re going to have to capture as much as you can. You will miss things, and requirements will change. That’s ok. You just need to make sure that you include this in your contingency time.

As I said before, get your development team involved early, and make sure that you run your UX and designs past them so that they can call out anything that might look ok in design, but that will turn out to be much more technically complicated than you’ll have initially thought.

Start scoping out on your boards, and use these as a single source of truth. Build your statement of work off the back of the tickets you put together in your project board. Personally, I would forgo with putting together a software architecture document - you should have everything the developers need in your tickets, and you won’t need to use it as part of your statement of work because this document should not be that technical.

Add contingency. I cannot stress how important it is that you don’t underestimate to win a bid. It will bite you in the ass hard if you do, and potentially damage your relationship with your client when the product that you promised will be done in12 weeks has crept into week 16.

Phase your features. Just because you're running fixed-price doesn't mean that you can't complete features and demo them in iterative cycles, as you would do with Agile sprints. This means you can get the client involved early and show off your progress.

If they change their minds about how something should work when they see it in anger. then you're capturing this mid-project rather than leaving all of their feedback to the end. And if they're adamant that it has to change to something that's outside of the agreed scope, then that's ok too - you can raise it as a change request, and negotiate additional time and cost for the project to cater for these changes.

All in all, never forget the tried and proven Agile practises just because you're delivering something where you're defining the entireity of the scope at the beginning. You just have to adapt it to make it work, as you should be doing for all of your Agile projects.