Simplicity: the Shortest Path to a Solution

Now, what is simplicity? Simplicity is the shortest path to a solution.
Say somebody does a proof for a mathematical problem in 20 pages. You study those 20 pages,
and finally you say, "Oh, I get it." You get a reward as the result of understanding that
proof, because the proof was a solution to an interesting problem, not just a difficulty.
Later, somebody else comes up with a 10-page proof for the same problem. Maybe the
new proof uses a branch of mathematics that you might have to study to master, but once
you master that branch of mathematics you can use it. And a 20-page proof becomes a
10-page proof. You'd have to say it's simpler, because it's a shorter path. Maybe it's
longer if you have to do a digression to actually learn a new branch of mathematics, but
let's assume that over time we realize that this branch is important to know in general, so
we all become familiar with it.

What we're really trying to do in software is find a way to make it easy to get value from
having solutions to problems. How do we do that? When we work the program, we put in
what we think is the shortest path to a solution. When we discover that the problem is
different than we thought, we rewrite. And then we rewrite again. We work the program.
That process is just like doing the proofs over and over. Sooner or later we discover that
instead of doing something in 30 lines of code, we can do it in 15 lines, because now we
have another capability that fits in. It really is just the right capability, so the work done
there we don't have to do here. We'll just invoke that capability from here. That makes
our solution easier to follow. Plus the effort you expend today to understand the code
will make you a more powerful programmer tomorrow. So that simplification is very
valuable.

If you write a lot of programs, and you're used to squeezing them all the time, you find
that it's easy to write a program that's simple. A lot of it is having a clear sense of what
you want to say—writing the proof by choosing what to prove, and being clear about
that. In programming, a lot of simplicity comes from knowing what matters and what
doesn't matter. A lot of times a program is made complicated because it's attending to
details that aren't needed, or could have been avoided, or could have been relegated to
something else.

Someone says, "You should always check your arguments to see if they're in range."
Someone else says, "Half the statements in this program are checking arguments that are
intrinsically in range." Have they made the program better or worse? No, I think they've
made it worse. I'm not a fan of checking arguments. On the other hand, there ought to be a
fail fast. If you make a mistake, the program ought to stop. So there is an art to knowing
where things should be checked and making sure that the program fails fast if you make a
mistake. That kind of choosing is part of the art of simplification.

Einstein said, "As simple as possible, but no simpler." He was being accused of being
complex, and he was saying "Yes, simple is important, but..." He'd taken a body of
observable fact that was unaccounted for, and accounted for it. So yes, his theory, his
models were more complex than Newton's, but they did more. They were worth
studying. He was saying, "Look, I made them as simple as possible, but no simpler."

So today, let's write a program simply. But let's also realize that
tomorrow, we're going to make it more complex, because tomorrow it's going to do more.
So we'll take that simplicity and we'll lose some of it. But tomorrow, hopefully
tomorrow's program is as simple as possible for tomorrow's needs. Hopefully we'll
preserve simplicity as the program grows.