Last week I was watching a panel session recorded at the GOTO conference last year. During this session Daniel North, the originator of BDD, made the analogy between surgery and software development:
No one wants surgery and if you really need it, you want the least amount of surgery to get away with. What people want is to be well and that their problems are solved. This also applies to software.
This comparison of software development to surgery reveals a truth about what we're really trying to accomplish as developers. Just as no patient walks into a hospital hoping for the most complex, invasive procedure possible, no user opens your application excited about the thousands of lines of code running beneath the surface.
What patients really want
When someone needs surgery, they don't want surgery, they want to be well. They want their problem solved with the least disruption, the smallest incision, the quickest recovery time possible. The surgeon's skill isn't measured by how elaborate the procedure is, but by how effectively they can restore health while minimizing trauma.
The best surgeons are often those who can look at a complex case and find the simplest path to healing. They know when a minimally invasive procedure will work just as well as a major operation. They understand that every cut carries risk, every minute under anesthesia matters, and every day of recovery is a day stolen from the patient's normal life.
What users really want
Your users are remarkably similar to surgical patients. They don't care about your elegant design patterns, your cutting-edge framework choices, or your impressive architecture diagrams. They have a problem, and they want it solved—preferably with minimal friction, maximum reliability, and the least possible disruption to their workflow.
When someone opens your project management app, they don't want to marvel at your microservices architecture. They want to create a task, assign it to someone, and get back to their actual work. When they use your e-commerce platform, they don't care about your sophisticated recommendation engine—they want to find what they need, buy it securely, and receive it quickly.
The craft of minimal intervention
The parallel between surgery and software development runs deeper than the end goal. Both require practitioners who can assess a complex situation and determine the least invasive solution that will effectively address the problem.
In surgery, this might mean choosing arthroscopic repair over open surgery. In software, it might mean using a well-tested library instead of building a custom solution from scratch. Both require the wisdom to know when complexity is necessary and the discipline to avoid it when it's not.
The most skilled surgeons spend years learning not just how to perform complex procedures, but when not to perform them. Similarly, experienced developers learn that the most elegant solution is often the one that requires the least code, touches the fewest systems, and introduces the minimal number of new concepts.
Code as incision
Every line of code is like a surgical incision—necessary for the operation but inherently creating risk. More code means more surface area for bugs, more complexity to maintain, more potential points of failure. Like a surgeon who makes precise, minimal incisions, a thoughtful developer writes only the code that directly serves the user's need.
This doesn't mean being lazy or cutting corners. A surgeon who makes a precise, minimal incision has usually spent considerable time planning, understanding the anatomy, and choosing the optimal approach. Similarly, writing minimal, effective code often requires more thought and skill than writing verbose, over-engineered solutions.
Recovery and maintenance
The surgery metaphor extends to the aftermath as well. Surgical patients need time to heal, and during recovery, they're vulnerable to complications. The more invasive the procedure, the longer and more complex the recovery process.
Software systems have their own recovery and maintenance phases. Simple, well-designed solutions tend to be more resilient and easier to modify when requirements change. Complex systems, like patients recovering from major surgery, require more careful monitoring and are more susceptible to complications.
The wisdom of restraint
Perhaps the most powerful aspect of this metaphor is what it teaches us about restraint. The best surgeons know that sometimes the most courageous choice is not to operate at all. They understand that their primary obligation is to "first, do no harm."
As developers, we can learn from this wisdom. Sometimes the best solution is not to build a new feature but to improve an existing one. Sometimes the most valuable contribution is removing code rather than adding it. Sometimes the right answer is to suggest a process change rather than a technical solution.
Building for wellness, not wonder
When we frame our work through the lens of wellness rather than wonder, our priorities shift. We stop optimizing for impressive technical demonstrations and start optimizing for user outcomes. We measure success not by the sophistication of our solutions but by how effectively they solve real problems with minimal overhead.
This perspective can transform how we approach technical decisions. Instead of asking "What's the most interesting way to solve this?" we ask "What's the least disruptive way to make our users well?" Instead of showcasing our technical prowess, we focus on delivering reliable, maintainable solutions that fade into the background while our users accomplish their goals.
The art of invisible excellence
The highest praise a surgeon can receive isn't about the complexity of the procedure they performed, but about how quickly their patient returned to normal life. Similarly, the highest praise for software might be when users forget they're using it at all—when the tool becomes so seamlessly integrated into their workflow that it feels like a natural extension of their capabilities.
This is the art of invisible excellence: creating solutions so well-suited to their purpose that they disappear, leaving only the value they provide. It's about building software that serves rather than impresses, that solves rather than showcases.
In a world full of over-engineered solutions and feature-bloated applications, the courage to build simply and purposefully isn't just a technical skill—it's a form of user empathy. It's the recognition that our users, like surgical patients, don't want our intervention to be the main event. They want to be well, to be productive, to accomplish their goals with minimal friction.
The next time you're faced with a technical decision, ask yourself:
Am I building for the patient's wellness, or am I building for the surgeon's ego?
The answer might just guide you toward simpler, more elegant solutions that truly serve the people who depend on your work.
You can watch the full panel session here: