Software Should Help People

Software is not an end in itself. It exists to solve problems for people. Every decision you make, from architecture to what library to use, should trace back to one question: does this help someone?

This sounds obvious. In practice, it gets lost surprisingly often.

The purpose of software

Max Kanat-Alexander puts it plainly in Code Simplicity: the purpose of software is to help people. Not to demonstrate technical skill or pad a résumé. To help people.

That framing changes how you think about everything. A feature that nobody needs is waste. An elegant solution to the wrong problem is still the wrong solution.

Start with the problem, not the solution

Simplicity does not start with code. It starts with the product.

Before writing anything, ask whether the problem can be solved in a simpler way. Maybe the workflow has unnecessary steps. Maybe two features could be one. Maybe it is not really a software problem at all and a conversation or a spreadsheet would do.

This requires genuine understanding of the problem domain. Surface-level requirements gathering produces surface-level solutions. The best software comes from teams that deeply understand what their users actually need, which is often different from what they initially ask for.

Continuous process

Helping people is not a one-time event. Software that helps today but becomes unmaintainable tomorrow stops helping. A quick fix that creates confusion for the next developer is not really helping either.

The principles in this section all serve the same goal: keeping software in a state where it can continue to help people, not just today, but next month and next year.