The spirit of the "Worse is Better" argument is generally not about implementation, but about design. Implementation is an artifact of design, it is a logical consequence. An implementation should be true to the design, and it should be competent. Nobody is advocating an implementation that does not work, or is a "hack" of poor quality.

In the context of WIB, "worse" strictly means "not as good", and is certainly not intended to mean "bad". Fundamentally, a case is being made that the simple, "not as good" solution is frequently better than the "better" solution. This is not unlike the old adage that "less is more". The number one principle of WIB is simplicity of design, a.k.a. "Keep It Simple Stupid", or "K.I.S.S.".

Simplicity of Design
So many times, some truly brilliant people have over-thought, over-designed, and over-engineered something to the nⁿ-th degree. The end product is an impressive sight, something so awesome that it could probably solve the riddle of the universe. If only you knew how to use it, that is. These works of "genius" are often inscruitable to anyone but the author and their close friends. As a result, nobody uses them because they are useless, or it will be used improperly and will erroneously be perceived as being useless.

This is why simplicity of design is vital. If the design is too complicated to be understood easily, then no matter how important or powerful the product is, it will not be used effectively.

Elegance is a way of taking something complex and making it very easy to use. It is about hiding the scary, complex things, and making them disappear. Then people wonder at their own skill, forgetting entirely the underlying power of their tool. In a single line of Perl you use thousands of lines of C code written by many individuals that are quite possibly far more skilled than you are, yet you aren't forced to learn more than is necessary to use it. The design humbles the program, making the power useful, it does not force you to raise yourself to the level of the program. You do not need a PhD to use Perl.

Avoid The "Golden Hammer"
The "Golden Hammer" is a program that is far too good for the task at hand. It is finely crafted, robust, elegant and powerful. It is everything that you could ever want in a hammer, and so much more. Yet a regular hammer will do the job just as well.

The "Golden Hammer" is not to be confused with the "Swiss Army Knife", as a Golden Hammer can only hammer, although it does it extraordinarily well. A Golden Hammer, put in a physical perspective, would have four wheel drive, bucket seats, air conditioning, a surround sound stereo, window wipers, traction control, ABS, and a really big hammer on the front that could nail anything in a single stroke with a precision of one-millionth of an inch. Unfortunately, it also took twenty to five hundred times longer to create than a regular hammer and takes three weeks of intensive training to operate safely.

WIB absolutely does not advocate using a rock, a screwdriver, or a piece of wood when a hammer is required. It simply advocates using a well designed, quality hammer that is easy to use and is understandable.

The interface should be simple, and sometimes simplicity introduces inconsistency. For instance, using a hammer's "claw" feature requires a change of grip from the normal "bash" feature. A "better" hammer could allow you to do both things from a single position, but would this truly improve the utility of the hammer? Would it make more sense, or would it just be showing off your engineering prowess?

Good Enough but Not Too Good
Simply put, make your program functional enough to get the job done well, simple enough to be understandable by others, and correct enough that it works under a wide range of circumstances.

It is better to have two problems solved than one problem over-solved.