Dr. Neil's Notes
Software > Development > The Fundamentals of Building Great Software Products
The Fundamentals will Outlast the Tools
Introduction
I have been building software for nearly forty years. In that time, the tools have changed beyond recognition. The fundamentals of building a product people can use have not.
I have worked on investment software, real-time bus information, freight systems, and interactive spaces where people gathered around a shared screen. The technology was different in each case. The questions that mattered were remarkably similar; who needs this, what are they trying to do, and what happens when the software meets the real world?
Some code I wrote decades ago is still running somewhere. I am not sure that is a recommendation for the code, however it is a useful reminder that software can outlive the tools and assumptions it was built with.
The tools change. The problem comes first.
It is easy to start with a technology. A new language, framework, or device arrives, and suddenly every problem looks like it needs to be rebuilt with it. Sometimes (rarely) it does. Often, the technology is more exciting to the people building the product than it is to the people who need the product.
Investment software had to help people make sense of information and decide on an action, or not. Real-time bus information had to answer a practical question for someone waiting for a bus, when their bus is going to arrive. Those are different products, but neither succeeds because of the language used to write it. The technology matters because it helps solve the problem, not because it is new.
Before deciding what to build, I want to understand the job people are trying to get done. A feature request is a useful clue, not always the answer. If we build exactly what someone asked for without understanding why they asked, we can deliver the wrong thing very efficiently.
A product is more than its code
Software does not arrive in an empty world, with perfect data and a user who has read the manual. It has to work with the device, the environment, the network, the people, and the processes around it.
That became very clear in interactive shared spaces. The experience was not just software on a screen. The experience involved people standing together, touching a shared surface, and trying to make sense of what they could do. The physical setup and the way people interacted with it were part of the product. If the software worked beautifully in a demo but people could not use it comfortably in the room, we had not finished the job.
Freight software makes the same point in a less theatrical setting. The value is not in having a clever screen. It is in helping people move their work through a complicated process, reliably enough that they can depend on it. Installation, support, and the way a product fits into existing work are not chores that happen after the product is built. They are part of what we are building.
Dependability is a feature
A product earns trust by doing what people need, when they need it. A bus information system that is beautifully designed but regularly wrong is not a great product. It is a very polished source of disappointment.
Correctness, performance, security, and accessibility all affect whether people can rely on software. These are not finishing touches to add if there is time after the exciting work. They shape the experience from the start. A product that excludes people or exposes their information is not great software with a small problem. The problem is part of the product.
We cannot prevent every failure, however we can decide how the product behaves when things go wrong. Clear feedback and a sensible recovery path are more useful than pretending the network, hardware, and users will always cooperate.
Build for change
The first release is not the last release. Users learn what they need, businesses change, platforms move on, and security expectations rise. Anyone who has maintained software for more than a few years will have discovered that yesterday's sensible decision can become today's interesting obstacle.
I have seen freight software continue to matter long after its original technology aged. Keeping it useful meant modernising it, not simply insisting that the old way was good enough. For forty years, automated builds and testing have helped me to make change more repeatable. They did not make every change safe by magic, they made it easier to find out when we had broken something before customers did.
Good architecture is not a prediction that nothing will change. It is a way of making future changes less painful. The goal is not to build an elaborate system for every future we can imagine. It is to avoid making the next sensible improvement unnecessarily difficult.
Release is where learning gets real
A successful demo shows that something can work. A product has to keep working when real people use it for real tasks, with ordinary interruptions, imperfect information, and no developer standing nearby to explain what to click.
A release gives us evidence. Are people completing the task? Where do they get stuck? What do they call support about? What did we assume that turned out not to be true? The answers should affect what we improve, and sometimes what we stop building.
This is also why a first release should be useful, not merely impressive. A small product that solves a real problem gives the team something to learn from. A large product full of features nobody needs gives the team a large product to maintain.
The questions I keep asking
When I am making a product decision, I come back to a few questions:
- Who is this for, and what are they trying to do?
- Will it work where and how people actually need to use it?
- Can people depend on it, and can we support it?
- How can we learn more after it is released?
- Will this decision make the next useful change easier or harder?
The tools will keep changing. We should use the good ones, and be willing to change how we work when the tooling makes something better possible. The purpose is still to build software that helps people do something worthwhile, and keeps helping them as their world changes.
The fundamentals outlast the tools because they focus on the people using the software and the problems it solves, not the specific technologies employed.
This is the first in a series of notes about the fundamentals of building great software products, with each note exploring a different aspect of creating software that remains valuable and effective over time.
Part of the Fundamentals of Building Great Software Products series.