---
author: "[[Bob Marshall]]"
tags:
  - blogpost
publish: 2026-04-28
sources:
  - https://flowchainsensei.wordpress.com/2026/04/28/honestly-what-is-software-for-what-is-software-development-for/
---
## Honestly: What Is Software For? What Is Software Development For?

It sounds like a question with an obvious answer. Software is for _doing things_. Running businesses. Sending messages. Booking flights. Playing games. Managing spreadsheets. The list is effectively infinite, and that infinity feels like the answer: software is for everything, and so software development is the craft of building everything.

But that answer is too easy. And easy answers to foundational questions tend to quietly mislead us — shaping how we work, what we prioritise, and what we believe about success — without us ever noticing.

The real answer is four words long. It will probably annoy you. It may reframe everything about how we work. And it implies something about what we actually _are_ — not developers, not engineers, not craftspeople — that we almost certainly didn’t sign up for.

So how about we take the question seriously?

### The Naive Answer: Software Is a Tool

The most common framing is that software is a tool — like a hammer or a calculator. It extends human capability. It lets one person do what would otherwise take ten. It lets ten people do what might otherwise be impossible.

This framing is useful and not wrong. But _it smuggles in an assumption_: that we already know what we want to do, and software merely helps us do it faster or cheaper. The tool is inert. It has no agenda. It simply amplifies intent.

The problem is that this isn’t really how software works. Software doesn’t just amplify whatever we want to do — it _changes_ what we want to do. It reshapes the landscape of possibility, and in doing so, it reshapes us.

Before spreadsheets, companies didn’t do the same financial analysis but slower — they did _different_ financial analysis, because certain kinds of analysis simply weren’t possible. Before search engines, people didn’t research things the same way but more slowly — they had different habits of mind, different tolerances for not knowing. Before smartphones, people didn’t navigate cities the same way but with more effort — they held maps differently in their heads.

Software isn’t a neutral amplifier. It’s a _medium_, in the McLuhan sense. And the medium shapes the message.

### A Better Frame: Software Makes Decisions Automatic

A more honest way to think about software is that it takes decisions _people_ used to make — and makes them automatic.

Every piece of software is, at its core, a set of decisions that have been crystallised into procedure. Someone, somewhere, decided: _when this happens, do that_. They wrote it down in code, and now that decision runs — without fatigue, without variation, at scale — forever.

Think about what that means. The programmer who wrote the logic for calculating an insurance premium may be long gone, but their reasoning runs ten thousand times a day. In this sense, software is less like a hammer and more like an institution — a set of rules and procedures that outlast any individual and shape collective behaviour.

This reframes what it means to write software. We’re not just building tools. _Behind every line of code are assumptions about people_ — what they need, how they behave, what matters to them, what happens when things go wrong. And those assumptions will play out, at scale, on real human lives.

### So What Is Software _Really_ For?

If we take this seriously, we get to a more honest answer: **software is for encoding assumptions about how the world should work, and acting on those assumptions — automatically, at scale, on real people.**

This is both empowering and sobering.

Empowering, because it means what we do is _a deeply human act_. It’s not just engineering or tech. It’s _philosophy_ made executable. Every design decision encodes assumptions about folks’ needs. Every edge case we handle (or don’t) reflects a belief about what matters to them. Every data model reflects a theory of what their world is like.

Sobering, because it means the stakes are higher than they look. The software that runs payroll, allocates loans, moderates speech, routes ambulances, or scores job applications isn’t just processing data — it’s making decisions that affect people’s lives, at a scale no individual human could. And unlike a human decision-maker, it doesn’t explain itself, doesn’t feel doubt, and doesn’t get tired of being wrong.

### The Only Principle We Need

I’ve spent decades working with software teams, and I’ve reduced what I’ve learned to a single principle — what I call the [Antimatter Principle](https://flowchainsensei.wordpress.com/2013/10/12/the-antimatter-principle/):

> _“Attend to folks’ needs.”_

Four words. My claim is that this is the _only_ principle required for effective collaborative knowledge work. The antimatter metaphor is deliberate: antimatter is extraordinarily rare, extraordinarily valuable, and annihilates with matter on contact. This principle, taken seriously, annihilates most of how software development is conventionally practised.

It’s worth unpacking each word, because the precision is the point.

**Attend to** means _pay active attention to_. Not “be vaguely aware of.” Not “document in a requirements spec.” Not “gather as input to a process.” Attend to — as in, make it the thing we are actually oriented towards, the way a carer or a therapist is oriented towards the person in front of them. See also: [Attentiation](https://flowchainsensei.wordpress.com/2025/06/16/attentiation/).

**Folks’** means _everyone involved_. Not just the paying customer. Not just the end user. The colleague who has to maintain the code. The team member whose working conditions shape what gets built. The stakeholder whose concerns never make it into a ticket. The person who will be affected by the system in ways nobody anticipated. Everyone.

**Needs** — and this is where it gets philosophically serious — means needs in the [Nonviolent Communication](https://assets.ctfassets.net/hw5pse7y1ojx/PKS3GhZG1sY0bmS0cqbGs/9d32ea9e934e2ad75b98b82f7b996d6c/Needs_Inventory.pdf) sense: the deep, universal human needs that underlie all behaviour. Safety. Autonomy. Understanding. Belonging. Respect. Contribution. Not _wants_, not _requirements_, not _feature requests_ — those are surface expressions of needs, often distorted by the way they get articulated through organisational processes. Needs are what’s actually _alive in people_.

The Antimatter Principle doesn’t ask us to attend to what people _say they want_. It asks us to attend to what they _actually need_. That is a much harder, and much more human, undertaking.

### We Are Not “Developers”. We Are Social Workers.

If the Antimatter Principle is right — if our practice is, at its core, the practice of attending to folks’ needs — then what does that make us?

Not _developers_. Not in any meaningful sense of the word.

(And allow me to challenge you to dispute the correctness of the Antimatter Principle…)

**We are social workers.**

This may disturb you. Huzzah! The disturbance is the point.

The word “developer” centres the act of _building_. It flatters us with the identity of craftsperson — someone whose excellence is measured in the quality of the artefact they produce. It quietly backgrounds the _people_ the software is built for and built upon, reducing them to inputs in a process: user stories, acceptance criteria, personas, tickets.

Social workers don’t have that luxury. Their practice is defined not by the artefact but by the _relationship_. They are accountable for understanding the people they affect — their context, their vulnerabilities, their unmet needs, the unintended consequences of well-intentioned interventions. They operate inside systems they didn’t design, with constraints they didn’t choose, and they are still responsible for attending to what is alive in the people they serve.

So are we. _We just haven’t been honest about it._ And I’ve never met a developer that could so be honest.

The identity of “developer” comes with a comfortable escape hatch: _I built what was asked. I wrote clean code. I shipped on time. What happened to [the Folks That Matter![™](https://s0.wp.com/wp-content/mu-plugins/wpcom-smileys/twemoji/2/72x72/2122.png)](https://flowchainsensei.wordpress.com/2018/06/22/the-folks-that-matter/) is someone else’s problem._The Antimatter Principle closes that hatch. The needs of the folks involved are not an input to our process. They are the _purpose_ of our process. If we’re not attending to them, we’re not doing the work — we’re just producing output.

This isn’t soft. It isn’t a feel-good addendum to “real” engineering. It is the harder discipline. It requires deep listening — to the people around us and to ourselves. It requires the courage to surface needs that nobody has put in a ticket. It requires staying in relationship with all the people our work affects, not just until the code ships, but as an ongoing orientation.

That’s social work. And it’s what we actually are.

### And Thus: What Is Software _Development_ For?

If software encodes assumptions about how the world should work, and the Antimatter Principle is the only principle we need, then software development is the practice of **attending to the needs of everyone involved — and encoding that attention into systems that act at scale**.

That reframe changes everything about what “good” means.

It means technical excellence is necessary but not sufficient. A beautifully engineered system that fails to attend to the needs of the people it touches is _not_ good software — it’s a precise instrument of _inattention_. Correctness isn’t about passing ‘tests’. It’s about whether the assumptions encoded in the system honour the real needs of the people it affects.

It means clarity matters — because opaque systems cannot attend to anyone’s needs. If no one can understand what a system does or why, it cannot be held accountable to the people it affects. Legibility is an _ethical_ requirement.

It means the “folks” in “folks’ needs” includes our colleagues, not just our users. The person whose needs for autonomy, understanding, and contribution go unmet will produce work that reflects that unattendedness. This isn’t a management insight. It’s a direct consequence of the principle.

It means needs change — they are alive, not static — and so attending to them is [a continuous practice](https://flowchainsensei.wordpress.com/2018/09/10/the-needsscape/), not a phase of the project. The assumptions we encoded six months ago were built on our understanding of needs at the time. Those needs have evolved. The gap between assumptions and reality is always growing unless we keep attending.

And it means the measure of success is not the system. It is whether folks’ needs are better met. Whether what is alive in people has been heard, honoured, and served. That is a humbler goal than “shipping software.” It is also a more true one.

### The Deeper Purpose

There’s a temptation to end a post like this with something grand: software is for _human flourishing_, or _democratising access to power_, or _making the world smaller_. These aren’t wrong, exactly. But they’re easy to say and hard to actualise.

The Antimatter Principle offers something more demanding: a practice, not a slogan. Attend to folks’ needs. All of the folks. All of their needs. Continuously, with genuine attention, giving from the heart.

That is what software development is for. And the name for people who do that — who orient their entire practice around the needs of the people they serve — is not “developer.”

It’s social worker.

Own that, and we start to become something more than builders of systems.

---

### Let’s Debate This

If you believe software is fundamentally about technology — that the human stuff is secondary, someone else’s job, or just a nice-to-have on top of the “real” work — I want to hear from you.

Not to score points. Because that belief is widespread, and widely consequential, and it deserves to be argued out in the open rather than talked around.

Find me at [flowchainsensei.wordpress.com](https://flowchainsensei.wordpress.com/) and bring your best case.

### Further Reading

Benson, J., & Barry, T. (2011). _Personal kanban: Mapping work, navigating life_. Modus Cooperandi Press.

Bridges To Life. (2005). _Needs inventory_ [PDF]. [https://assets.ctfassets.net/hw5pse7y1ojx/PKS3GhZG1sY0bmS0cqbGs/9d32ea9e934e2ad75b98b82f7b996d6c/Needs_Inventory.pdf](https://assets.ctfassets.net/hw5pse7y1ojx/PKS3GhZG1sY0bmS0cqbGs/9d32ea9e934e2ad75b98b82f7b996d6c/Needs_Inventory.pdf)

Marshall, R. W. (2013, October 12). _The Antimatter Principle_ [Blog post]. Think Different. [https://flowchainsensei.wordpress.com/2013/10/12/the-antimatter-principle/](https://flowchainsensei.wordpress.com/2013/10/12/the-antimatter-principle/)

McLuhan, M. (1964). _Understanding media: The extensions of man_. McGraw-Hill.

Rosenberg, M. B. (2015). _Nonviolent communication: A language of life_(3rd ed.). PuddleDancer Press.

---

_“Attend to folks’ needs.” — [The Antimatter Principle](https://flowchainsensei.wordpress.com/2013/10/12/the-antimatter-principle/) (2013)_

_“We are NOT ‘developers’, we are social workers.” — [#AntimatterPrinciple](https://sw-development-is.social/tags/AntimatterPrinciple)_

_The question “what is this for?” is worth asking early and often — not just before we start building something, but all the way through. The answer changes as we learn more. That’s not a flaw in the process. That is the process._