Every one reading these words has no doubt worried over a problem or two until the answer has become clear. Generally, the best answers are the simpler ones, primarily because we’ve done some thinking, and gotten rid of the unimportant details that cloud the real issue (whatever that may be).

The problems in programming are much like that. Get anyone to write code as soon as they hear the problem, and get ready for a mess of code. Give that same person some time to think it over, and the mess gets cleaned up. More time, more planning, and the code is even clearer.

However, while we’re waiting for software to get better and more thought-out, companies have to ship something. And so we get to learn from programmers’ first attempts. And second, and third, and as many as it takes to get it right. With this tradeoff between impatience and planning, there ends up being plenty of opportunities to ‘get it right’ for the next version.

Like many of the other factors involving complexity, changing it is an enormous task. However one possibility might be in adjusting our requirements. Start small with a well-understood problem, and build up, thereby getting a handle on the complexity. But no matter what, one thing we programmers can do everywhere is think first, and code later.