Software is mostly made of people
Code is just one of many critical ingredients to cultivating value.
Speaking with a colleague of mine the other day, I came to what I feel is an even deeper realization of how organic a working, value-producing software application really is.
We were talking about how it was difficult to understand some of the idiosyncrasies of one of the parts of our system that’s owned by another team — all of whom were on vacation at the time. Fortunately we could wait until they were back from vacation for us to ask them.
It did, however, make me realize that without all these people working together, collaborating and communicating frequently, the software really wouldn’t have the positive impact in the world that it does. Reflecting on it further, I’d go as far as to say that in general, value-producing software is first people, and then the code that they produce.
From tech- to people-centred
This perspective stands in stark contrast to my own perspective when I was much younger. I (foolishly) aimed to build software that would just take care of itself — build it once (perfectly, without bugs, LOL), users would flock to use my software and give me money, and I’d never need to look at it again. Kind of like publishing an award-winning book and then watching the royalties flow into my bank account. It was a misguided perspective that put the machine and the code at the centre of my paradigm as opposed to all the humans who were there in the background the whole time, but whom my paradigm wouldn’t allow me to see. It also vastly overestimated my powers of intuition to really know what users wanted or needed.
Over the years I’ve encountered so many developers who, like me, put technology at the centre of their paradigms — folks who have the “build it and they will come”, or “build it and we’ll worry about users, operations, maintenance, support, etc. later” mentality that I used to have. This post is an encouragement to people with such a paradigm to try to look at their craft from a different perspective.
Software is primarily made of people
When I write of “software” here, I’m referring to running, value-producing software — the kind that people use to make their lives better in some way. This sort of software is so much more than just code:
For software to exist in the first place, it needs developers.
For software to run, it needs to run somewhere and someone needs to ensure that it’s working optimally: it needs operators.
For software to produce value, someone needs to use it, and get value from using it: it needs one or more users. Even software libraries, which aren’t ever run directly, have users: other developers.
For software to continue to produce value over time, someone needs to adapt it to users’ evolving needs and its environment: it needs maintainers.
When software fails to provide the value it’s supposed to, users need someone to whom they can reach out and ask for help: it needs support.
The code of the application is just a thin layer of technology facilitating value-producing interactions between all of these people: consumers and cultivators, to put it another way. It’s a crucial part of that set of interactions, of course, but it’s by no means all-encompassing.
Conway’s Law, which is just as relevant in 2025 as it was back in the 1960s when the idea was introduced, illustrates how people-centric just the development process is:
[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
Martin Fowler even speaks of an inverse Conway’s manoeuvre (originally from this article by Jonny LeRoy and Matt Simons), where if you want to change the overall structure of a large software application you first restructure your organization to reflect the desired high-level software structure and let natural communication patterns do the rest.
Implications
One of the biggest implications from this paradigm shift for me was in how I now think about building and running software-based businesses.
When I was younger, I focused exclusively on the technology and assumed that everything else would fall into place. In recent years, however, when thinking about software-based business ideas (ones where there’s a real user need first), I think to myself: what kind of team would I need to make this a reality, and what kind of environment do we need to cultivate for that team to encourage healthy engagement with each other and our users?
There are other implications for this paradigm shift, of course, largely relating to the influence of individual and group psychology on the way that software is built and evolves over time. I hope to write about my experiences and observations along these lines in the coming months.