KISS Me Quick

There's quite often a difference between what people are impressed by when your trying to sell them on a product, concept or idea and what they actually want come delivery time.

Bells and whistles will draw gasps initially but when they actually come to use your code they just want it to work, is being brilliant 80% of the time better than being fit for purpose 100% of the time?

Its unfortunately quite common place for a simple idea to be turned into a complicated implementation, what takes real skill is to engineer beautiful simplicity.

Worse Is Better

In 1989 Richard P. Gabriel described a principle that was summarised as "Worse is Better", this principle pitched the idea that quality does not necessarily grow with functionality.

"In software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed." 

Using this model, four principles are applied to a design in descending order of importance.

First and foremost a design should be Simple both to implement and to use, simplicity should never be sacrificed to meet any other criteria.

Secondly a design should be Correct in all observable aspects, but it is better to be simple than correct.

Next a design should be Consistent but in driving for consistency we should not end up with an overly complicated implementation, especially when the inconsistent parts of the design would be on the periphery of the system.

Lastly a design should be Complete, but no other quality of the design should be sacrificed in the pursuit of completeness.

You Aren't Going To Need It

At the the heart of the application of these design principles is the concept of YAGNI.

Too often a simple design is contorted into a confusing mess in an effort to cover every possible eventuality. While ideally a design would be full-proof we should prefer a simple well understood design that will be fit for purpose in all but the most extreme situations.

It will be much easier to think through how such a solution can be adapted to meet changing future requirements than to produce a rigid unmaintainable but complete design up front.

Complexity Costs

Unnecessary complication ultimately costs,

• It costs the developers time to implement.
• It costs the testers time to test.
• It costs the customers time to understand the system and report the bugs that will undoubtedly exist.
• It costs more of the developers and testers time to fix the bugs and introduce new functionality.

Paying this cost to implement a feature or cover an edge case that isn't going to be needed makes little sense.

Following these principles isn't an excuse to not think things through, complexity should be measured relative to the problem thats trying to be solved.

A system designed to put a satellite into space will by most peoples standards be complicated but the same rules should apply, someone who understands the problem should smile at the simplicity of the solution.

Customers can be very unforgiving, they are unlikely to be impressed by the brain powered required to produce a monolithic all encompassing design if they can't figure out how to use it or it continually fails under the weight of its own complexity. What they will ultimately be satisfied with is something that does what it says on the tin, day in, day out.