The thing is that simplicity could be right under a programmer's nose, already done, and they will pass right over it. They will start building something new when a simple solution already exists for what they are trying to do.

Some people just want to write code. No matter if it needs to be written or not. It's like nervous energy.

The important question that we fail to address in arguments about simplicity is "What is it you are trying to do?"

Most times, it's a simple thing. Or it's a number of different things, each of them simple. But the programmer cannot see it that way. He envisions something else. He envisions a large project. He fires up his "IDE". We're doomed, heading for complexity from the start.

What if the simple programs are boring? What if they are short? What then? The programer is itching to code something, anything. He's going to do it. He will produce something complex and unleash it upon the world.

He will have to use "features" to sell his work. (Chances are it will be very similar to other existing programs.) As such, his program can never just do one thing. It must do many things. It must have features. Because that is the only way he can convince people to try it.

Some users will bite. Success! Or is it? This how we end up with an overly complex monstrosity.

What if programming is really a boring task of writing simple, efficient, reliable programs? Then what?

We'd be nowhere without UNIX. And it's a simple boring (well, not to me) system. There is no GUI. But it works. Take some time to process that.

You do not need to create simplicity. (All due respect to STEPS.) You simply need to wake up and discover it. It's running your system. It's right underneath your nose.

Discover, not create.