Doing Software Wrong

Nobody reads the Markdown

Steve Townsend — Tue, 14 Jul 2026 00:00:00 GMT

Our repositories have stopped being just a safe home for our codebase, they have become a noticeboard.

Markdown files have appeared everywhere, each one containing another set of instructions for the agents now wandering through the project like contractors on their first day, nodding confidently while having no idea what they are doing.

Look at any modern code repository and there they are.

AGENTS.md
CONTRIBUTING.md
ARCHITECTURE.md
DECISIONS.md
HOW_THE_IMPORT_BIT_WORKS.md
READ_THIS_FIRST.md
READ_THIS_FIRST_ V2.md

This isn't necessarily a bad thing, and here is why.

Documents are one of the best ways to give AI agents context. Models can write code extremely well. They can translate specifications into implementations, follow patterns, produce tests, and confidently invent a function that already exists three folders away.

However, they are less adept at knowing what we meant when we gave them the prompt that generated the specification in the first place.

It is in this intent - what we actually mean – that most of the software's value lies.

It's the work around the work.

In The forklift and stapler, I wrote about task engineering.

I wrote about why we need to stop giving AI systems tiny instructions and start giving them designed pieces of work; why we need to give them tasks.

To do that, we need to paint the picture of what we need, define what 'done' looks like, and leave room for the agent to make decisions.

Which sounds excellent until you realise what we have invented.

More documentation, a developers' arch nemesis.

We don't expect developers to write every word themselves. We have AI now, and we can generate 17 pages of technically immaculate prose before someone has finished saying, "Should we document this?"

But generating documentation is not the difficult bit. The difficult bit is taking responsibility for it. And that responsibility is sitting firmly on your shoulders.

Agents are your teammates

Your agents can read the code, make changes to it, and sometimes complete an unsettling amount of work. What they can't do is absorb the invisible information that exists between us humans. This includes historic organisational decisions, past compromises and unwritten rules (i.e. the thing nobody touches because Sarah once said not to).

For agents the code is visible and readable, whereas the understanding and intent is not.

Documentation is what we use to fill the gaps that exist between the code of the software and the intent of the system. We need documentation to tell the agents how the system is supposed to work, any constraints that exist and where previous developers discovered holes in the floor.

Your tour guide is operating with an outdated manual

Imagine the documentation in your repo is a tour guide showing a new employee (your agent) around a large factory. Reassuring at first.

"This way to the accounts teams."

"Safety equipment is stored in the orange cupboard, marked 'Safety'."

"When you finish your shift, press the big red button beside the loading bay."

But what if the documentation hasn't been updated for years, the accounts team changed buildings, the safety cupboard now contains Christmas decorations and a printer nobody remembers buying?

As for that red button near the loading bay, it's now blue and pressing it releases a thousand litres of custard.

Armed with the documentation, the tour guide speaks with unwavering confidence, but they are catastrophically wrong.

If you gave that same documentation to an agent and asked it to modernise the factory, things would go wrong fast.

Documentation generated (or otherwise) without ownership is more dangerous than ever because agents trust the documentation.

Trust is new development dependency

For agents to work effectively across a team, the team needs to trust each other's documentation. This is not simply trust that a document exists. It is trust that a document matters, that it is accurate, it has been reviewed, and trust that it will be kept up to date.

This work cannot be entirely delegated to the AI that generated it either, in the same way you wouldn't ask someone to write their own performance review, approve it and award themselves a pay rise accordingly.

An agent can draft a document, review it against code to find inconsistencies and suggest improvements, but a developer needs to decide whether the document reflects the system, whether it reflects reality.

A key component of our new role is judgement. The model does more of the typing, we do more of the judging.

The hopefully useful bit

I wanted to share a checklist for evaluating your documents, because most of the bad ones look fine until you check them.

When you are next working on a document for your project, ask these 5 questions:

Does this document have a specific purpose? Can you explain who uses it, and what decision or task it helps them complete?
Is it still true? Check it against the code, configuration and current behaviour rather than trusting its confident little Markdown smiley face. As I mentioned above this is something AI can help you with, just check its work.
Does it explain the intent as well as the mechanics? "The system does this" is useful, but "The system does this because changing it would anger the payment processor" completes the picture.
Is it concise and is it understandable? No document is improved by becoming a complete oral history of the repository. A document is also useless if only an agent can understand it. Make sure your non-agent team members would know what the document says.
Is it clear when it needs to be updated? If the document can become stale without any obvious trigger or owner, it will.

If a document fails any of these checks, you should fix it or delete it if the content is no longer relevant.

Doing software wrong in plain text

Markdown files (or other flavours of document) have become very important, especially as agents take on larger pieces of development work.

But this only works when the documents can be trusted. While AI has made documentation almost free to produce, it hasn't made it any less expensive to own.

We as developers need to review the documents, challenge them, and occasionally remove six pages of total nonsense before another agent mistakes it for the constitution. We need to own them, not just ship them.

Otherwise, we have not painted a better picture for our AI teammates, we have simply automated the production of un-helpful content at a scale previously available only to large government departments.

As usual, we will be doing software wrong.

But in Markdown instead of C#.

The forklift and stapler

Steve Townsend — Fri, 26 Jun 2026 00:00:00 GMT

Most developers have become pretty good at using AI, some reluctantly.

We paste in an error and ask for an explanation. We ask for unit tests, a regex we will immediately regret, or a slightly less deranged version of a comment we wrote at 11:47pm while bargaining with a build pipeline.

And it works. The model helps. The developer moves on. Everyone feels faintly productive, like something meaningful has happened.

Recently I have been feeling like what is being achieved is persuading a very expensive machine to help tie our shoelaces.

The more I look, the more I see it.

Developers are not really giving the AI models real work; they are giving it instructions.

Very precise, mostly small instructions. We have been trained by what are now old limits. Prompts shaped by working with models that punished you the moment you got ambitious.

Until very recently if you gave a model something too large, too messy, or too close to reality, it would start out with a great plan. It would outline the problem with calm authority. It would list the trade-offs. It would appear to understand the system, the context, the intent, the whole little ecosystem.

Then, somewhere around step four or five, it would quietly detach from reality and float away like a lost party balloon.

As developers we adapted, because developers are strange creatures that will build an elaborate ritual around a tool even if it keeps biting them.

We have become prompt bonsai artists, carefully clipping away ambiguity until the model cannot hurt itself or anyone nearby.

Prompt engineering was useful, obviously, and sensible for the models we had, but wrong for the models we are getting.

Models like Claude Fable 5 and Sakana Fugu are not just asking us to write better prompts. They are asking us to engineer better tasks. Not "say the magic words more clearly", but "define a real piece of work, gather the materials, describe what done looks like, set goals so the model can make judgement calls and leave a trail a human can review afterwards."

For me that is a different muscle entirely.

And I do not think most developers have trained it yet. Not because we are lazy, or stupid, or insufficiently excited about the future of agentic development. It is because we have been trained by smaller models to think small, to be explicit, hover nearby, and prompt for fragments instead of outcomes.

We have become excellent at dealing in fragments.

We are less practised at shaping work.

Prompt engineering was useful. Task engineering is different.

Don't get me wrong — clear instructions matter. Context matters. Examples matter. Telling the model what good looks like matters.

But prompt engineering, as we usually talk about it, belongs to small interactions, it belongs to fragments.

You ask. It responds. You adjust. It responds again. You both continue this little dance until either the problem is solved or you have spent 40 minutes arguing with an agent about bullet formatting and need to go outside to kick something.

Task engineering is different.

Task engineering is not about crafting the perfect prompt. It is about designing a piece of work in a way that a capable model can do it.

You are not prompting the model.

You are commissioning work.

Which feels slightly pompous, so let's immediately ruin it with a forklift.

The forklift and the stapler

Imagine someone buys a warehouse forklift.

A proper big yellow beast. Warning beeper. Rotating light. The kind of machine that gives anyone in a high-vis vest a feeling of authority. It can lift pallets, move heavy loads, rearrange a warehouse, and, if handled poorly, punch a new doorway through a wall.

Now imagine the team discovers it is useful for moving staplers.

Someone stands on one side of the office and says, "Can you bring me that stapler?"

The forklift driver nods, lowers the forks with impressive precision, slides them under the stapler, lifts it with the dignity of a royal procession, reverses slowly, beeping all the way, and delivers the stapler.

Technically, this is a success.

The stapler has moved. The forklift performed the task. No one died, which in software counts as a green build.

But after a while, you would start asking whether perhaps the team had misunderstood the forklift.

This is where a lot of AI use in development is heading. We have these increasingly capable systems, and we are using them to pass staplers.

Rename this. Summarise that. Write a helper. Convert this into YAML, the cursed lasagne of configuration formats.

There is nothing wrong with small tasks. Small tasks exist. Small tasks matter. Sometimes the stapler really does need to be moved, and if the forklift is sitting there, fine, have at it. But if every interaction is a stapler task, the forklift does not change the warehouse. It just makes office stationery more theatrical, and far less economical to share.

Fable 5 makes the forklift problem obvious. With Fable, tiny tasks are not just wasteful, they are eyewatering expensive.

Sakana Fugu makes the metaphor worse, because now it is not one forklift. It is a warehouse system that can decide whether the forklift, pallet jack, conveyor belt, barcode scanner, or Dave from dispatch should handle each part of the job.

Fugu is interesting because it treats orchestration as part of the intelligence.

That changes the question from "what work should I ask the model to do?" to "how do I design work for a system that can route, coordinate, verify, and combine different kinds of model effort?"

Which is a much bigger question than "please make this function nicer".

Bigger work, structured work

Fable and Fugu point at two different problems hiding inside the same upgrade.

Fable points at bigger work. What happens when the model can carry more than we know how to hand over?

The old developer habit is to stay close. Watch the output. Correct every drift. Keep the model inside a safe little paddock where it can graze on helper functions and not frighten the horses. That made sense when the model needed constant supervision, but it becomes a bottleneck when the model can work for longer.

Instead of hovering over every step, the developer needs to frame the work properly up front and review the result like an owner.

That is a different kind of discipline.

Fugu points at structured work. What happens when the model is no longer one thing doing one thing?

But serious engineering work is rarely one kind of thing.

Real work to solve real pain needs exploration, planning, code reading, implementation, testing, verification, risk assessment, documentation, and rollback thinking. A single model can attempt all of that, but an orchestrated system can treat the work as a sequence of specialised moves.

It means developers need to stop thinking only in terms of "the answer I want back" and start thinking in terms of "the work process I want the system to run".

Not just "solve this".

More like: inspect this, compare options, identify risk, attempt a solution, verify it against the constraints, tell me what remains uncertain, and produce the smallest next step that would let a human decide.

That sounds suspiciously like engineering, unfortunate for anyone who hoped the future would be less work.

The new work is specifying work.

A lot of developers are extremely good at implementation and much less practised at saying what the real job is.

It may feel wasteful to spend an hour or three preparing the material to engineer a task for a seriously big model — it can easily feel wrong because the marketing version of AI productivity is always someone typing a sentence into a glowing box and receiving a miracle before their oat latte gets cold.

But serious work has never worked like that.

If you spend three hours building the right context pack and the model saves you two weeks of grinding investigation, that is not inefficiency. That is as close to a miracle as we can get.

This is also where Fable and Fugu should change how we think about cost. If a model is expensive, slow, or powerful, then using it for cheap little tasks is not disciplined. It is like booking a surgical theatre to trim your fingernails.

The value is moving.

As the doing gets cheaper, deciding gets more expensive.

As implementation gets faster, framing matters more.

If models can chew through larger chunks of work, the scarce skill becomes knowing which chunks are worth chewing.

If you were hoping AI would remove the need for judgement, bad news. The judgement bill has arrived, and it has itemised charges.

Doing software wrong at the wrong size

So this is probably the next bit of doing software wrong.

We will get access to bigger and bigger models. We will keep asking tiny questions. We will spend premium reasoning tokens on boilerplate, summaries, and functions our IDE could have written while asleep. We will complain that the results feel underwhelming.

Then someone will hand the model a properly scoped, painful, valuable job with enough data and a clear definition of done, and suddenly it will look like witchcraft.

It will not be witchcraft.

It will be preparation, which is less exciting but much more useful.

The future is not developers sitting back while models do everything. The future is developers learning to see larger work. The work that was too big to assign, too boring to prioritise, and too painful to do manually.

That is the real shift. Not prompt engineering. Not magic. Not job apocalypse. Task engineering.

The ability to see the bigger job, package it properly, give it to the model, walk away long enough for it to work, and come back ready to judge what it did.

We will still get it wrong. The model will still get it wrong.

That is software.

But maybe we can start getting it wrong at the right size.

Because if the models are getting bigger and our questions stay tiny, the failure is no longer entirely in the machine.

The question was too small.

And as usual, annoyingly, expensively, we are doing software wrong.

We’ve Accidentally Created Infinite Features

Steve Townsend — Wed, 08 Apr 2026 00:00:00 GMT

The productivity bit is real

Recently, I had one of those deeply suspicious moments in my software career where something starts working so well you immediately stop trusting it.

Not in the dramatic sense. Nothing caught fire. Nobody sent an email that made me feel nauseous. There wasn’t even a keynote involved, which already puts it ahead of most modern technical revolutions. It was just the quiet, disorienting realisation that working with AI had made me, and the team around me, noticeably more productive. Properly productive. The kind of productive where work that used to take a hard week is done before lunch, and looking smug about it.

I don’t mean this in the vague nonsense way people say “productivity” when they really mean they’ve cancelled three meetings and ordered a nicer chair. I mean actual progress. The work moves. You can get from rough idea to plausible feature much faster than before. You can explore options without feeling like every experiment is going to cost three days and a minor emotional collapse. You can spend less time chiselling individual lines of code out of the side of a mountain and more time thinking about what the feature is supposed to do in the first place.

One of the best side effects of AI in a development team is that your focus gets to shift upward. Away from the time consuming business of writing code and more towards understanding the shape of the thing. What does this feature actually need to do? How should it behave? What are users trying to achieve? Where are the awkward bits? What happens when the normal happy flow goes off-road and ends up upside down in a ditch?

That is good work. Proper work, even. Software has always improved when developers spend less time doing syntax carpentry and more time trying to describe what the thing is actually supposed to do.

But for years, we quietly defined the job as the code.

That was the craft. The identity. The bit you could point at and say, “this is what I do.”

AI has made that definition feel incomplete.

Because now the code turns up quickly, sometimes suspiciously quickly, and you’re left staring at the bit we used to treat as more of a side quest: deciding what should exist in the first place, and whether it’s going to behave itself once real people get involved.

There is a massive benefit here. Most of the effort has moved from typing to thinking, which is lovely, because typing was never really where the value lived. It was just where the back pain lived.

Finishing is now the hard part

But, and this is where software once again shuffles onstage wearing a fake moustache and pretending not to be the same old problem, the productivity uplift is now the new problem.

Because once you can produce work at warp speed, once the barrier between “we could do this” and “here is a working version of this” gets low enough, your brain starts doing what human brains always do when presented with new power. It becomes insufferably optimistic. You stop seeing a feature as a bounded piece of work and start seeing a thousand adjacent possibilities bobbing around it like overexcited ducklings.

You sit down to finish one thing and suddenly you’re not really finishing it anymore. You’re expanding it. Improving it. Noticing three other things nearby that could also be improved while you’re in the area. You are five minutes away from adding a form and somehow end up halfway through redesigning a workflow because the machine made the first bit easy and now your mind has wandered off into a nearby field, drunk on possibility.

I know this because I do it myself. I’m not reporting from a great height here like some stern Victorian headmaster of software discipline. I am one of the idiots in the room getting excited.

This is where finishing starts to suffer.

Not because people care less. Almost the opposite, really. It’s because people care so much, and can suddenly imagine so much more, that the satisfying, boring, necessary business of finishing one thing completely begins to feel a bit provincial. A bit small. A bit like staying home to do your taxes when there’s a whole theme park outside and someone has just handed you unlimited ride tokens.

And the sometimes unpleasant truth about software is that finishing is the job.

Not starting. Not ideating. Not marvelling at all the wonderful things we might be able to build before the kettle boils. Finishing. Rounding it out. Closing the gaps. Checking the edges. Dealing with the weird state transitions, the ugly error cases, the boring validation, the miserable user path where somebody uploads the wrong file, double-clicks the button, loses their connection, and then phones support as if you personally have hidden their documents in the woods.

That work still exists. AI has not made it disappear. It can help with parts of it, obviously. It can help generate tests, suggest edge cases, document behaviour, untangle logic, and generally act like a very keen assistant who never gets hungry or asks whether any of this is really the best use of our brief time on earth. But even with that help, there is still a big chunk of evaluation and validation that has to be done by people who understand the system, the product, the trade-offs, and the various exciting ways in which reality tends to ignore our assumptions.

Currently that evaluation, at least for me, does not move at the same speed as generation.

That’s the mismatch.

Because the more AI helps you produce, the easier it is for the team to start feeling that everything can be fixed just as easily. The logic goes a bit like this: if it took less time to build, surely it will take less time to repair. If changes are cheaper, maybe mistakes are less serious. If iteration is faster, perhaps caution is a touch old-fashioned, like adding your name to a waitlist for a new VHS release at Blockbuster.

This is where your brain tries to start skipping steps.

Not in some villainous way. Nobody sits there twirling a moustache saying, right, let’s recklessly under-test a feature and see whether we can make support cry. It’s subtler than that. You just feel the temptation to move on a little sooner. You tell yourself the final pass can happen later. The edge case can be tightened up in the next round. The weirdness in the workflow probably isn’t weirdness, it’s just one of those things that feels odd because it’s new. Besides, if it is broken, we can fix it quickly. We’re fast now.

Maybe you can. In fact, many times you can. That is what makes it dangerous.

Because once “we can fix it quickly” enters the room, process starts getting treated like a polite suggestion. The last twenty percent of the feature, which was already less glamorous than the first eighty, starts to look almost optional. Not entirely optional, obviously. Just a bit flexible. Something to circle back to after this one interesting idea, and then the next one.

AI has given the team jet skis

The metaphor that keeps turning up in my head is that AI has basically given the whole team jet skis.

Now, a jet ski is undeniably fun. I have never seen a sad person on a jet ski. That’s part of the issue straight away. It is fast, responsive, and deeply exciting to the person operating it. You do not gently potter about on a jet ski reflecting on the virtues of restraint. You zip. You skim. You turn aggressively for no real reason. You become, for a brief and stupid period, the sort of person who thinks spray counts as progress.

That’s a lot like my current feeling of building with AI. You can move so quickly across the surface of things that it all starts to feel thrillingly manageable. More features. More variations. More experiments. More tight turns and bursts of speed. Everyone’s having a marvellous time, carving elegant loops across the water and shouting, “look how fast we’re going”.

The problem, unfortunately, is that software is not a nice open ocean on a sunny afternoon. It is a marina full of posts, ropes, hidden debris, tired old structures, and other people trying to do something sensible nearby. There are rules. There are depth markers. There are bits where you’re absolutely meant to slow down, though nobody likes admitting that. There is also, somewhere off to one side, the poor users standing on the shore, trying to work out why six new vehicles have appeared, all of them half-fuelled, one of them parked at a café, and none of them apparently having passed a proper inspection.

Then because this is a metaphor and I have clearly lost control of it, support is the harbourmaster, operations is a rescue boat, the product owner is shouting that one of the jet skis was only supposed to be a paddle board, and the executive team is asking whether this means we now have capacity to open a water park.

That’s roughly where we are.

Not doomed. Not ruined. The uplift is real. The shift from writing code to understanding and describing functionality is real. The increased ability to explore ideas is real.

It’s just that the bottleneck has moved, and moved in a way that messes with your head.

The problem is no longer just getting software produced. The problem is holding your attention steady enough to finish what you started when five more exciting options are now within arm’s reach. Validation still takes time. Judgment still takes time. None of the old boring responsibilities have gone away just because the front end of the process has become dramatically more fluid. Speed creates optimism, and optimism has always been one of the leading causes of software being done wrong.

So I think that’s the new version of the old mistake.

For years we thought the pain was in getting the code to work, and now that some of that pain has lifted, we’re discovering the deeper discomfort was elsewhere all along. It was in deciding clearly. It was in finishing properly. It was in resisting the urge to wander off halfway through the feature because another shinier idea just popped out of the machine wearing sequins.

AI has made teams more capable. I believe that. It has also made distraction more productive, which is an absolutely ridiculous sentence to have to write but seems to be true. You can now make a surprising amount of progress in the wrong direction before lunch, and do it with such confidence that by the time anyone notices, the room is full of half-rounded features and cheerful explanations about how easy it will be to sort them out later.

Sure, maybe it will be easy.

But later is where software goes to become expensive.

So yes, enjoy the uplift. Use it. Shift your attention upward into understanding the product better, because that is where the real value has been hiding all along. Just keep an eye on the other thing AI has quietly made easier, which is getting so excited about what could be built next that you forget to finish the thing right in front of you.

Because it turns out the hard part was never really writing the code. It was knowing when to stop doing loops of the bay at speed and come back to the shore.

Confessions of a reluctant Luddite

Steve Townsend — Tue, 17 Feb 2026 00:00:00 GMT

I had a moment this week where I genuinely considered becoming a Luddite. Not in a dramatic, delete-all-my-accounts way. In a proper, roll-up-the-sleeves, gather-the-villagers and smash the machinery sort of way.

Because I realised something slightly unsettling.

I am in a new Industrial Revolution, and I am the one weaving the textiles.

Last time I wrote here, I was still comfortably speculating that the change in my job was coming “soon.” Soon is a wonderfully stretchy word. It gives you room. Soon can mean next year. Soon can mean after the next roadmap. Soon can mean once everyone else has figured it out. Now it just means today.

I’ve been working with the latest generation of AI models recently. Not here to start a pub brawl about which brand is superior. What matters is the step change. The jump from “helpful autocomplete with good manners” to something that feels like a suspiciously competent colleague who has quietly read your entire codebase and formed opinions.

Large, complex parts of our system are becoming easy to modify. And that word, 'easy', feels like a betrayal.

This is a codebase that grew the way coral reefs grow. Slowly. Layered. Accreted through time and compromise. It contains old architectural ideas, half-finished refactors, comments marked “temporary” that have survived multiple federal governments. Changing it used to require care. You didn’t just edit a file. You negotiated with history. You reasoned through side effects. You felt your way through it like someone defusing a bomb built by your past self. That was the craft.

Writing code wasn’t just output. It was the thing. The careful but clumsy naming. The shaping of a function so it read cleanly. The quiet satisfaction of refactoring something awkward into something almost elegant. You chase a kind of singularity of perfection that you never quite reach, but you enjoy the pursuit. You refine that over decades. You build a career on it. If I’m honest, you build a bit of your identity, your “being” on it.

And now I can describe a change in English in a simple prompt, hand it to a small pool of AI agents, and they go off like diligent mill workers. They update functions, adjust tests, restructure modules, and return with a pull request and a tidy summary of what they did and why. I review. I merge. I move on.

It feels like I’ve been hand-weaving textiles for years, obsessing over thread tension and pattern symmetry, and suddenly someone wheels in a steam-powered loom. Not just any loom, either. One that reads your sketches, suggests improvements, fixes your inconsistencies, and doesn’t get tired. I am still in the factory. But I am no longer holding the shuttle.

That’s the Industrial Revolution part. Not in a smoky Dickensian way. There are no soot-covered children and no factory whistles. There is just a quiet shift in who does the weaving and at what speed.

Part of me is genuinely thrilled. I have always loved new technology. I was the kid mesmerised by a CD-ROM encyclopaedia because it had moving pictures on a screen that wasn’t monochrome. Later I was burning my own CDs like some suburban DJ convinced I had bent the universe to my will. New tools have always felt like magic to me.

But magic hits differently when it starts absorbing the part of your craft you loved most.

I didn’t expect to feel a small grief about writing code. Yet here it is. The act itself, the slow shaping of logic, the wrestling match with a tricky bug, the quiet flow state of getting something just right, that was arguably the most fun and creative part of the job. The bit I’ve spent decades refining.

Now I spend less time writing and more time describing. Less time implementing and more time directing. The creativity hasn’t vanished, but it has moved up a level. It’s in the framing of problems, the clarity of instruction, the judgement about what should exist at all. When code becomes cheap, judgement becomes expensive.

And that is both exciting and unnerving.

There is a part of me that wants to gather a small band of romantics and smash the machines. To insist that craftsmanship matters, that hand-written code has soul, that we will not surrender our looms without a fight. But this is not 1812. The machines are not in a shed down the road. They are in global data centres the size of suburbs. You cannot smash them. You can barely conceptualise them.

So the Luddite fantasy fades quickly into practicality.

The real shift is not that I am being replaced. It’s that my role is dissolving and reforming around me. I am less the carpenter and more the foreman of a factory floor full of robotic arms. They are tireless, context-aware, occasionally wrong but fixable in minutes. They do not care about the poetry of a well-named variable. They care about producing output.

If I zoom out, this is exactly what an Industrial Revolution looks like. The skill doesn’t disappear. It gets abstracted. It gets scaled. It gets embedded into machinery so that fewer people need to practice it directly.

We will, of course, handle this badly. We will measure success by pull request volume. We will generate more code than we can sensibly own. We will confuse velocity with value because the graphs look impressive. We will industrialise the wrong parts first, because that is our particular gift as an industry.

The turning point has already happened for me. The change I thought might take another year or two is in my repo today. My job is not vanishing, but the part I loved most is being quietly automated away.

I am still excited. I am still that kid staring at a glowing screen thinking this is magic. I am just also aware that I am no longer weaving every thread myself. And if history tells us anything, it’s that we are about to do software wrong on a scale previously reserved for textiles.

I won’t have a job soon. Apparently.

Steve Townsend — Thu, 22 Jan 2026 00:00:00 GMT

There’s been a weird tone creeping into all my conversations lately.

Not loud panic. Not screaming. Just… a moderate, constant hum. The kind you notice when you stop and realise everyone around you is talking a bit faster than usual.

Friends ask how work’s going, but they don’t really mean it. Colleagues phrase things like questions that are actually stress tests. People who’ve been calm for years suddenly say things like, “So… how worried are you, actually?”

And it’s not just tech. Markets are wobbling. Numbers on screens are doing that thing where they drop and bounce and drop again. The price of gold has gone absolutely bananas, which historically means humans have collectively decided they do not trust anything anymore.

Gold only does that when people are scared.
Not rational scared.
Primal scared.
Cave-painting scared.

And in software, that fear has found a very specific shape.

“Is this… still a job?”

Nobody phrases it dramatically. That would be embarrassing.

Instead it comes out sideways.

“I’ve noticed fewer junior roles lately.”
“Are you using AI much?”
“Do you think it’s still worth learning to code?”

These are not technical questions. They’re career survival questions wearing hoodies.

Underneath all of them is the same thought:

Is this thing I’ve built my life around about to quietly disappear while I’m still paying off a laptop?

And look - it’s not helped by the constant drumbeat of predictions. Software engineering is always apparently six months away from being dead. If you’ve been in the industry long enough, you’ve heard this announcement so often it’s started to feel seasonal, like flu warnings or end-of-year performance reviews.

But this time it’s different, they say.

Because this time there’s AI.

I’ve already been obsolete once

The thing is, this isn’t even the first time I’ve been told my career was ending.

The last time this happened - or at least the last time it happened this loudly - it was app builders.

You might remember them. Or maybe you’ve successfully repressed the memory.

They were going to democratise software.
They were going to empower “regular business users”.
They were going to let anyone drag, drop, and click their way to software supremacy.

No developers required.

That was the pitch.

Somewhere around the early 2010s, every second demo involved a smiling product manager assembling an app on stage like it was IKEA furniture.

Look - a button.
Look - a form.
Look - an entire mobile application built in fifteen minutes while a developer quietly contemplated retraining as a barista.

They had friendly names. App builders. Visual builders. Low-code. No-code. Tools that promised software without software people.

And for a while, the panic was real.

Because the promise was always the same one we’re hearing now:

“Why would you need developers when the business can just build it themselves?”

What actually happened last time

Here’s what didn’t happen.

Developers did not disappear.
Software did not magically become simple.
Complex systems did not politely collapse into drag-and-drop rectangles.

What did happen was familiar.

These tools were great at simple things.
Internal tools.
Forms.
Dashboards.
Prototypes that looked convincing enough to get budget approval.

And then reality showed up.

Because the moment someone asked for:

real integrations
real security
real performance
real edge cases
or anything involving “just one small exception”

…a developer was summoned. Usually urgently. Usually late.

The business-built apps either grew until they needed engineering help, or quietly died and were replaced by something “more robust”, which is management speak for “we’re hiring engineers again”.

The tools didn’t kill the profession.

They just changed the edges of it.

Which should sound extremely familiar right now.

The mistake we always make

The mistake we always make is pretending this is a purely technical question.

Every discussion about AI replacing developers eventually lands on the same argument:

“Is the technology good enough yet?”

Can it write code?
Can it debug?
Can it design systems?
Can it replace people?

But that’s only half the problem. The other half is people. And people are the reason software has never behaved the way the diagrams said it would.

Here’s the uncomfortable truth:

Even if AI-generated code was terrible - for example, didn’t compile, hallucinated APIs, confidently broke production - it still wouldn’t stop companies from trying to replace engineers with it.

Because leaders don’t adopt technology based on technical correctness. They adopt it based on optimism, pressure, and the haunting fear of being the last person at the table not “doing AI”.

So whether AI can replace programmers is only 50% of the equation.

Whether people believe it can is the other 50%.

And belief has a long, proud history of ignoring reality.

Like many things it's a spectrum

At one end of the spectrum, AI automates every technical job, the economy collapses, and it doesn’t matter what you studied because society has turned into a slow-moving apology.

At the other end, AI never improves beyond today, companies lose interest, and everything stays basically the same forever.

Neither of those is going to happen.

Reality, as always, is messier and more annoying.

The job survives, but stops looking like the job

My prediction is the job survives, but stops looking like the job.

What’s already happening - quietly, unevenly - is that AI is eating the boring parts of programming.

The loops.
The boilerplate.
The test scaffolding.
The documentation.
The deployment pipelines.
The code you never loved but had to write anyway.

Developers aren’t vanishing. They’re just typing less.

The job shifts toward:

making architectural decisions
translating vague human desires into something a system can survive
debugging when the AI confidently claims it fixed the issue and absolutely did not
understanding how large systems fail in ways nobody predicted

This is why the junior market feels strange. The traditional “learn syntax by suffering” path is shrinking, while the ability to reason about systems is becoming the actual work much earlier.

What we used to call “senior skills” are slowly turning into table stakes.

Coding isn’t the job anymore. It’s the literacy.

When people ask if it’s still worth learning to code, they’re usually asking the wrong question.

The real question is whether it’s still worth understanding how software works.

And the answer to that is yes - because everything else depends on it.

You can’t debug what you don’t understand.
You can’t supervise AI output if you don’t know when it’s lying politely.
You can’t make good decisions about systems you can’t read.

Typing code might become optional.

Understanding it will not.

Or the job disappears and comes back with a new name

Another possibility - maybe later down the track - is that the job disappears and reappears under a different name.

There’s a future where “software engineer” quietly stops being a title, not because the work is gone, but because it’s reorganised.

Instead of writing code, technical people:

oversee AI systems
investigate when those systems build the wrong thing
design workflows that stop automation from amplifying mistakes
explain to leadership why “just let the AI handle it” has again caused fire

Because even in a heavily automated world, decision-makers still want a human to tell them what to do. Accountability doesn’t scale as well as software does.

And the future - whatever else it is - is still extremely technical.

The uncomfortable, boring conclusion

If your dream was a career spent typing code by hand forever, untouched by automation, then yes - that’s probably a risky bet.

But if you’re comfortable adapting, learning, and doing work that sits around code rather than inside it, then no. It’s not too late.

The fear is understandable. When markets shake and gold spikes, everyone starts scanning the horizon for exits. Software people are no different.

But software has always been wrong.
The predictions have always been wrong.
And the job has always changed faster than the headlines admit.

If you feel unsettled, uncertain, and slightly behind no matter what you do - congratulations.

You’re not failing.

You’re just falling into the trap of thinking you are doing software wrong.

Exactly like the rest of us.

Process is not your saviour

Steve Townsend — Tue, 09 Dec 2025 00:00:00 GMT

Sometimes there is that person in a meeting - the one whose Miro board is a web of arrows and sticky notes like a detective’s evidence board - who announces that the reason everything is on fire is because we are not following The Process™.

If you have ever been part of a development team you are probably familiar with the moment.

Everyone else is staring at the floor, wondering if now a good time is to fake a coughing fit or a heart attack, and this person is pointing earnestly at a burndown chart like it’s the missing map to the Ark of the Covenant and they are Indiana Jones.

According to them, all we need to do is follow the steps.

Stand-ups, retros, peer reviews, planning poker, Fibonacci fibbing, sprint planning, Kanban cleansing, whatever the ritual is.

Just follow The Process™ and all shall be well; the fires will be extinguished and software delivered on time.

It is adorable, honestly.

The part no one wants to admit

Want to know a secret?
The process barely matters.

I know, it’s heresy. Put the pitchforks away - at least for a moment.

Of course, a good process helps. It brings order to the chaos and avoids the need for late-night emergency “HOTFIX” commits on a broken build.

But a process only works when the people using it actually want to work together.

When the team cares about the problem. When they want to solve it, not just move tickets around like they’re playing a Scrum-themed shell game.

There is no process in the world that can fix a team that fundamentally does not want to be a team.

This is the part missed in many methodology books.

You won’t find it highlighted in the Agile Manifesto or any of the glossy product-management presentations that look like they were designed by a TED Talk intern.

Software is less a project with an end date and more a relationship that never really ends, no matter how much you want it to.

Software is a relationship Between humans. Who are famously terrible at aligning on anything.

Developers vs the real problem

In my experience developers love a good technical puzzle.

Give them a weird concurrency issue or an API that returns something that looks like JSON but smells like pain, and they’re happy for days.

But people problems? Holy shit.

You’d think you’d asked them to refactor their childhood trauma.

The minute the challenge becomes interpersonal instead of technical - misaligned expectations, unclear decisions, passive-aggressive Slack messages, that one product owner who schedules meetings at 4:30pm on a Friday - developers disengage.

They retreat back into the safe warm glow of their editor windows, where the only arguments are the ones in their own code.

This is also why I believe support and production work turns so many developers into functioning adults. It forces them to confront… people. Real ones. With feelings. And caps-lock keys.

Row, row, row your boat

Imagine your team is a rowing crew.

Now, imagine half the team is rowing, a quarter is arguing about whether rowing is technically the right process for going forward, one person is refactoring the oar because “the old one was inefficient”, and another person is scared of conflict, so they’ve quietly slid off the boat and are swimming beside it hoping no one notices.

And the process consultant - clipboard, sun-visor, the whole aesthetic - is yelling from the riverbank:

“You’re not following the process; your stroke is not in the correct sequence!”

Mate, the stroke sequence is the least of our problems.

We’re sinking. Some of us are literally in the water.

A rowing process only works when the crew wants to row in the same direction.

Software is no different.

Humans first, technique second, oars third, and maybe a boat if we’re lucky.

It’s never about the process

Yes, follow a process - it might help you sleep at night.

But don’t build a shrine to it.

Don’t pretend it’s going to rescue you from miscommunication, apathy, or that one teammate who reads Jira tickets with all the focus of a cat glancing at a vacuum cleaner: vaguely aware something is happening, but absolutely not engaging.

Software is hard because people are hard.

The tech is always the easy bit. Tech problems sit still and wait to be solved.

People problems multiply like well-fed gremlins after midnight. They’re renewable, persistent, and forever eager to ruin your day.

The teams that manage to get it right - or at least less wrong - are the ones who actually give a shit.

They want to build something together.

They treat collaboration as a team sport instead of an optional side quest.

They tolerate each other’s habits long enough to get the thing out the door.

Almost any process works to deliver software when the people care.

Not a single one works when they don’t.

If that sounds grumpy? Good.

If it sounds dismissive of The Process™? Also good.

Because if you are building software and trusting The Process™, you’re almost certainly doing it wrong - exactly on schedule.

The framework isn’t for you. You’re just along for the voyage.

Steve Townsend — Thu, 04 Dec 2025 00:00:00 GMT

I was trying to build a survey form. Just a text box or two, a dropdown maybe, and a button. Nothing crazy – no fancy gradients, no animations that make buttons behave like they are auditioning for a Pixar film. Just a boring, run-of-the-mill form with a button that says “Submit”.

Five minutes of work, I thought. Maybe ten if I forgot how HTML works again.

Many hours later I had installed a CLI, a bundler, selected a starter template, and more packages than Santa delivers to the nice kids at Christmas. It started as a tiny task, and now I’m in dependency purgatory wondering if the form even needs to exist.

At some point, while watching my editor freeze under the weight of its own node_modules folder, I started suspecting the form was no longer in my control. It had outgrown me.

It had ambitions. This wasn’t a form anymore. This was a journey. A voyage.

And the framework, whatever it was, had quietly promoted itself to captain.

The realisation that the framework has its own agenda

This is the part no one tells you when you reach for a JavaScript framework: it wasn’t built for you.

Oh, it wants you to think it was. It wants you to feel special. It whispers sweet promises like:

“Look how fast we hot-reload!”
“Look how elegant our file structure is!”
“Look how little code you have to write!”

But that’s bait. Pure developer catnip.

Because frameworks are built for a lot of reasons, and almost none of those reasons are “so your product will be delightful, stable, and low maintenance for you or for your users.”

The reasons frameworks are built are one or more of the following:

the maintainers’ careers
corporate influence
ecosystem dominance
conference applause
and the irresistible urge to reinvent a perfectly functional wheel using 80% configuration and a touch of YAML - also known as the “I can do that better” argument.

What about your users, your deadlines, and your actual business needs?

They weren’t even in the room.

Frameworks are entire worlds bent around the desires of the people who build them. And that’s fine, mostly. As long as you understand the deal.

Why frameworks are free, and why that should concern you slightly

They are free because if they weren’t, nobody would use them.

They are free because adoption equals power.

They are free because “free” lets creators test ideas on thousands of unsuspecting developers who just wanted a dropdown.

And when something is free, you are not the customer.

You are the product.

You wouldn’t download a free dog and then complain that it barks. You wouldn’t be gifted a free house only to demand they repaint it mauve.

But with frameworks, we not only look the proverbial gift horse in the mouth - we complain about its breath.

We act shocked that we don’t have any say in how they evolve.

Why would you? It’s free.

This is how you end up the reluctant owner of a cargo ship

At some point in my little form adventure I had a realisation:

I didn’t pick a framework. I boarded a cargo ship. A cargo ship that I own but I am not in charge of.

I wanted a small rowboat - something small and calm, something simple. Yes, it may be a bit leaky, but it would be fine for my purposes.

But instead, I ended up on a vessel that can only turn if the moon is in the correct phase.

The framework is enormous. It has opinions. It has mechanisms. It has interfaces that interface with other interfaces that you never asked to interface with anything.

It wasn’t built for my tiny cross-the-river errand. It was built for transoceanic routes, shipping lanes, ballast calculations, and complex global logistics I will never understand.

And just like a real cargo ship, it’s going to require a crew, a maintenance schedule, a surprisingly large amount of fuel, and a commitment to learning what all those buttons do.

One does not simply “add a form” on a cargo ship. One schedules a deployment window, checks the tide, files the documentation, rebalances the containers, and hopes the weather holds.

The twist? It’s okay, as long as you know the deal

Here’s the thing. Frameworks aren’t bad. They aren’t villains. They aren’t plotting against you, even if the documentation occasionally feels like a trap.

They’re just… not for you.

They’re built for the ecosystem, for the maintainers, for the job market, for the people who love building frameworks.

You’re allowed on board. You’re even encouraged to wander around and touch the machinery. But you are not steering the ship.

The moment you accept that, everything becomes less frustrating.

Yes, the framework will change in ways that inconvenience you. Yes, the next major version will break something, if not everything important. Yes, the migration guide will be vague in all the places you needed it to be specific.

But that’s the price of being a passenger on someone else’s vessel.

Your job is to get your form built and shipped without falling overboard.

Doing software wrong, nautical edition

We all want to believe we are in control of our tools. That the choices we make are rational and centred around our users. That a framework is a partner who has our backs, rather than a large industrial machine humming under our feet with little care if we succeed or fail.

But the truth is simpler, and slightly funnier:

Sometimes you’re not doing software so much as hitching a ride on someone else’s engineering adventure.

And that’s fine.

It’s wrong, of course. But it’s the kind of wrong that everyone is doing, loudly, proudly, and with a nauseating number of dependencies.

Now if you’ll excuse me, I need to update my form. Which, judging by the size of this vessel, is probably going to require a couple of tugboats, and a local pilot, and maybe a bribe.

Plug it in and make it magic

Steve Townsend — Wed, 26 Nov 2025 00:00:00 GMT

There’s a new phase in the corporate lifecycle - somewhere between “we need to modernise” and “someone please find the person who owned this spreadsheet” - where an executive suddenly sits up, eyes glowing with the confidence of someone who has not read a single technical document since 2009, and declares:

“We need AI.”

It’s said with the certainty of a man spotting a new cordless tool in Bunnings. They don’t know what it does, but they want, no, they need it in the garage.

No one asks what problem AI is supposed to solve.
No one asks whether the data is ready.
No one asks why the company still can’t reliably onboard a new starter without summoning three separate departments and a ritual sacrifice.

Because asking questions complicates things. And executives don’t want complexity.

They want magic.

The comforting illusion of the ‘AI Strategy’ slide

There’s something soothing about the idea that AI will glide into the organisation like a benevolent wizard, tap its wand on the servers, and suddenly all the messy, human, organisational nonsense will sort itself out.

Staff will stop entering dates in 14 different formats.

Old processes will melt away like snow in spring.

Those systems nobody has touched since all the monitors were big ivory boxes will become “integrated”.

In the executive imagination, AI arrives the same way the hero does in a Marvel movie: just in time, perfectly choreographed, hair blowing in the breeze.

Never mind that the data is a series of disconnected puddles in a swamp of different machines.

Never mind that your workflows require a map, a compass, and emotional resilience.

Never mind that half your systems communicate via Excel export as attachments and hope.

Magic is appealing. Reality is not.

But reality keeps poking its head round the door

The uncomfortable truth is that AI is perfectly capable of solving problems - just probably not your problems.

At least not until you fix:

the processes everyone follows differently
the workflows nobody owns
the data pipelines held together with sticky tape
the reporting layer built entirely by Bob, who retired without handover
the documentation last updated just after the dinosaurs died.

Companies want AI the same way people want a robot vacuum: press the button, walk away, and imagine the house is gently tidying itself while you contemplate your leadership principles.

But AI is not the robot vacuum itself. AI is more the moment you finally buy a robot vacuum, set it loose, and discover that your home is 60% cable spaghetti, 20% abandoned socks, and 20% “mysterious debris.”

The robot doesn’t clean - it loudly and enthusiastically alerts you to every corner of your home you have neglected for a decade.

And AI behaves the same way:

You didn’t want a vacuum.

You wanted the comforting illusion that your mess would remain theoretical.

The “Magic Button” problem

There is always - always - someone who asks if AI can just “look at all our data and tell us what’s wrong.”

This is organisational astrology. They want the AI equivalent of reading star charts: “Your KPIs are low because Mercury is in retrograde… and also Karen keeps overriding the CRM data manually.”

They want a glowing dashboard that says:

AI SUMMARY: EVERYTHING IS FINE EXCEPT THAT ONE TEAM YOU SECRETLY SUSPECTED ANYWAY.

They want the machine to be omniscient, decisive, and conveniently aligned with their pre-existing biases.

And maybe, one day in the far future, when our brains are uploaded to servers and nobody uses spreadsheets anymore because we’ve evolved past pain - maybe then AI will tell you your organisational destiny.

But today?

AI is basically the world’s most sophisticated amplifier. Whatever mess you give it, it will give you back a louder, more expensive version of that mess.

AI as a metaphorical house renovation

Think of AI like hiring a tradie to renovate your kitchen.

You call them in, expecting new worktops and sleek appliances, the whole Pinterest perfect fantasy.

But the tradie walks in, looks at the walls, taps a few beams, and says: “Yes, lovely idea, but your house is actually… well… a bit shit.”

Then they take out their iPad full of photos of all the flaws, faults and expensive f#$k ups in your house you didn’t want to see.

This is what most AI projects are: a very polite professional pointing at everything structurally wrong with your organisation.

The data silos? Rotten floorboards.
The 87-step approval process? A load-bearing mistake.
The operational workflow written by someone who left in 2014? An electrical hazard wrapped in nostalgia.

AI reveals the nonsense. It does not cover it up with quartz countertops.

The deeply unsexy prerequisites of “being ready for AI”

If companies truly want AI to work - really work - they need to do the things that never make it into keynote speeches:

define a process
stick to the process
pick a single source of truth
clean the data
centralise the data
stop emailing Excel sheets around like digital carrier pigeons
retire systems old enough to vote
document everything - literally everything.

AI is not the prize you get for announcing ambition. AI is the prize you get for doing the boring, tedious, organisational homework that everyone has avoided for years.

And yes, this is exactly why so few companies actually get value from it.

Doing software wrong… but now with a robot

This is just the next chapter of the same saga we always live through:

the belief that software becomes “done” just because it ships
the belief that support is someone else’s problem.

AI doesn’t replace these delusions. It simply adds a shiny chrome finish. You’re not supposed to get it perfect. You’re supposed to get it less wrong than yesterday.

Fix your data.
Fix your processes.
Fix the ancient systems quietly decaying in the corner like a neglected house plant withered and drying to dust.

Then - and only then - AI will stop being a corporate fantasy and start being genuinely useful.

And if that feels disappointing, congratulations.
You’re doing software wrong. Exactly as intended.

The best education your developers never got

Steve Townsend — Tue, 25 Nov 2025 00:00:00 GMT

I didn’t start my career thinking I’d one day be yelled at by a stranger because a button didn’t do what they expected. Or that I’d have managers calling me demanding to know why someone’s data had "f%$ked off into the ether”, as though the system had achieved sentience and developed a personal grudge.

But here we are.

If you’ve never supported software, you probably imagine an inbox with a few polite bug reports. Maybe a suggestion here, a gentle query there. Lovely.

What you actually get is a crash course in human emotion under duress.

That’s where developers really learn how software works - not on their expensive laptops in perfect conditions, but in the messy, angry, unpredictable wild.

The moment everything falls apart

You can write code for years without realising what it’s like on the support side of the fence. The side where user emotions are raw, stakes are high, and people have absolutely no interest in whether your sprint velocity improved this quarter.

I still remember the emails.

The angry ones.
The ones written entirely in CAPITAL LETTERS.
The ones that arrive at 6:13am before you’ve had a Red Bull and are essentially hate mail directed at a function you refactored three months ago.

And then there are the managers who absolutely lose their shit because a user spent hours entering data that “just disappeared”. You try to explain that the workflow wasn’t designed to do that, or that their browser session expired, or that pressing back three times and refreshing does not do what they think it does.

They don’t care. They’ve lost tens of thousands of dollars. And they want someone - ideally you - to explain how this could possibly happen in software that was “done”.

Nothing teaches you faster. Nothing teaches you harder.

It’s character building in the same way being chased by a magpie is “good exercise”.

Support is the real classroom

Once you’ve spent time supporting a live product - not imagining support, not simulating it, actually living inside it - your entire perspective shifts.

You start to realise:

Logs are not optional.

They’re the forensic evidence you need when someone insists the system “ate” their data. Without logs, you’re arguing with ghosts.

Metrics are oxygen.

You suddenly care deeply about memory spikes, queue lengths, request times, error ratios, and that one mysterious metric that starts climbing for no reason at 2am.

Monitoring helps prevent disasters.

A simple alert can save you from an awkward call where someone asks, “How long has the system been down?” and you realise the truthful answer is, “Longer than I’d like to admit.”

User behaviour is chaos.

You build a feature expecting users to do A → B → C. In production, they do B → C → X → pray → restart their computer.

Designing software without ever supporting it is like parenting by only reading the books, and never raising a child.

In theory, it’s all very orderly. In reality, something shitty is happening, and someone is crying.

Developers who only build don’t know how to build for reality

When a developer has never supported a product, they tend to think:

“The requirements were met. Job done.”
“This edge case is unlikely.”
“The logs are fine, I only needed then to test this worked anyway”
“We don’t need that alert - we’ll notice the issue.”

This is how systems go down silently at 3am. This is how users lose work. This is how expensive, reputation-denting mistakes happen.

A developer who has felt production pain starts coding differently:

They add logs everywhere because every missing log becomes a future argument.
They write error messages with the clarity of someone who has been yelled at.
Exceptions are really that, an exception, something completely unexpected.
They guard against edge cases because they’ve learned users live in edge cases.
They create dashboards and alerts before adding fancy features.
They think about recovery steps, not just happy paths.

Support turns developers into grown-ups, sometimes traumatised grown-ups, but grown-ups nonetheless.

The product mindset or owning your shit

Support forces a shift from project mindset to product mindset.

Project mindset: “We built it. Ship it. Move on.”

Product mindset: “We built it. Now we protect it, improve it, and learn from it.”

Project thinking is tidy, convenient, and great for executive presentations.

Product thinking is messy and real, because it acknowledges that software is never finished, and that users will always find new and exciting ways to break things.

If you’ve never supported a system, you can’t truly design a good one.

You don’t know what’s coming.

You haven’t lived through the 2am outage, the frantic rollback, the weird bug triggered only by people using Internet Explorer 9 on a hospital kiosk.

You’re doing software wrong unless your developers know the world beyond the Dev, Test and UAT.

In the end, you’ll still be wrong - just less wrong than before

Supporting your own software doesn’t make you perfect.

It makes you humble.
It makes you aware.
It makes you better.

You will still be wrong.
Users will still complain.
Something will still go wrong at an inconvenient time involving a stakeholder who begins every sentence with “I thought we agreed…”

But developers who’ve supported their own work are wrong in smarter ways. They’re wrong with better logs, better alerts, and better assumptions. They’re wrong - but recoverable.

And that’s the quiet truth behind Doing Software Wrong:

You’ll never do it right in everyone’s eyes. But supporting what you build gives you a fighting chance of doing it less wrong than the day before.

Just hit deploy and you’re done

Steve Townsend — Mon, 24 Nov 2025 00:00:00 GMT

There’s a particular moment in every software project where someone leans back in their chair, exhales deeply and says, “Well. It’s done.” It’s said with the confidence of someone who has not yet opened their inbox the next morning.

The idea that software becomes “complete” the moment it goes live is weirdly persistent. It’s held by people who should know better and people who definitely don’t, and it offers the same seductive comfort as believing that buying gym membership automatically gives you fitness. If only the universe worked like that.

But software has never obeyed the rules of “finished”. Even the U.S. Defense Innovation Board, who are famously not known for whimsical metaphors, describe software as something that is never truly done and must be “managed as an enduring capability”. They talk about it the way you might talk about a heritage building or a problematic uncle. It’s always going to need work.

It’s always going to need attention.

Developers know this. Designers know it. Anyone who’s ever tried to upgrade an operating system knows it. But for some reason, the myth survives, the belief that the release is the exhale after a long sprint rather than the inhale before the next one.

The comforting deception of “Done”

There’s something very soothing about the illusion of completion. It makes budgets look tidy. It makes roadmaps appear achievable. It reassures board members who would prefer not to hear the word “iteration” ever again.

But the moment you treat software like a finished sculpture, you’ve already guaranteed it will age badly. Software lives out in the world. It reacts to things. Browsers update. Phones change shape. A third-party library quietly rots in a corner. Users behave in ways no rational person could predict. Suddenly your app is coughing like a toddler who has just started daycare, and everyone is wondering who approved the design.

The truth is much closer to what Henrik Warne wrote in his blog about maintenance: software doesn’t have two phases - development followed by maintenance - it’s all the same continuous process. New code becomes old code very quickly. “Maintenance” is just the polite word for “keeping this thing alive because we have unleashed it into reality”.

Software as something that breathes… and sometimes wheezes

Think of software like a garden. You can’t just plant a row of tomatoes and walk away forever. Leave it alone long enough and the bugs move in, the weeds throw a rave, and soon the whole thing is unusable. Software behaves the same way. Ignore it and it decays, even when nothing “breaks” in the traditional sense.

Security “bugs” arrive with alarming enthusiasm. Standards evolve. User expectations creep in and take over like weeds. The world never stays still, and your product is dragged along with it whether you like it or not.

The marriage you didn’t realise you entered

This is where the marriage analogy comes in handy. People joke about “committing to a codebase”, but the comparison is fairly solid. The launch is the wedding day - lots of excitement, many photos, perhaps a small cake. But the real work happens afterward.

If you don’t keep showing up, the relationship suffers. Things get brittle. Things drift. You find yourself one day staring at a giant, expensive mess and wondering how it all fell apart. Some companies even go through the tech equivalent of divorce - a full rewrite - and emerge poorer, wiser, and promising never to let it get this bad again.

It’s not glamorous, but it’s honest: if you want to get value out of your software, you have to contribute to it continuously. If you don’t, the software will eventually pack its bags and find someone who will. Or, more likely, your customers will.

What this means for anyone actually building things

If you’re running a company, leading a team, or founding something ambitious, the mindset shift is simple. You’re not building a product that ends. You’re stewarding a product that grows.

This affects how you plan. It affects how you budget. It affects who you hire and how long you expect them to stay. It means acknowledging that the moment you ship version 1.0, version 1.1 is already knocking politely in the hallway.

It also means resisting the urge to cram in everything at launch, because there will be time later. Iteration is not a punishment, it’s your friend. You don’t need to achieve perfection in the first go, it’s impossible. Even the best teams and the most experienced leaders all discover that something they believed to be true before launch is later revealed to be… extremely wrong.

And you know what? It’s fine. It’s the whole premise of Doing Software Wrong. You will always be wrong in someone’s eyes. A user, a reviewer, an engineer on the internet with a suspicious amount of free time. The point is not to be right forever. The point is to care enough to keep improving.

If you think you’re done, You’re already behind

The release isn’t the end. It’s the beginning of the part that actually matters.

If you claim your software is finished, all you’re really saying is that you’ve stopped paying attention. And in this industry, not paying attention is the fastest path to becoming a cautionary tale.

Celebrate the launch. Enjoy the moment. But don’t imagine for a second that you’ve reached the final chapter. You’ve just turned the page to the part with more footnotes, more deadlines, and more unexpected plot twists.

You’re not done. You never will be. That’s the fun and the frustration of it. If you feel slightly uneasy about everything you’re doing… congratulations. You’re doing software and you’re probably doing it wrong, exactly as intended.