start as simple as possible

Revision as of 09:12, 16 December 2014 by Pfefferle (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)

Jump to: navigation, search

One of several microformats principles.

short url:


solve simpler problems first

Main article: solve-simpler-problems-first

Large problems can often be difficult to solve and seemingly require complex solutions. Instead start with:

start with a simpler solution

Start with a simple solution with few features, rather than a complex solution with many features.

Often, the simplest possible solution turns out to be the most effective solution. No more work is needed.

When given the choice of two solutions to a problems, start with a simpler option, which can be accomplished effectively and immediately, and find any actual shortcomings from experience. Avoid starting with a more complex option which may a priori deem to solve conceptual or theoretical chimeras; possibilities that might have a general impact when implementing the solution, but then again might not.

minimal vocabulary

Main article: minimal-vocabulary

One way of keeping a solution simple is to minimize the vocabulary that the solution uses, and certainly of those, minimize any new vocabulary that are introduced.

Minimizing the vocabulary used for properties (and values) of a microformat helps keep the microformat easier to understand.

Minimizing the introduction of new vocabulary is particularly important. Doing so:

make evolutionary improvements

When any solution is designed and implemented, it is inevitable that some shortcomings will be found in practice.

It is better to find a few shortcomings, which can be addressed through iterative improvements, than find out that you have spent time designing features which few if anyone uses in practice (but may have already cost developers time to implement, nevermind the hours/days/weeks of design-time debate).

Microformats should remain as simple as possible for as long as possible, collecting additional element semantics only when a significant practical need has been demonstrated for such additions.

When such shortcomings/needs are found in practice, they should be documented, along with the practical instances.

If there are sufficient instances (say, near ~80% as mentioned previously), then add improvements that address the specific shortcoming (avoid the temptation to add more generic improvements unless a need is demonstrated for such a broader improvement), and iterate as necessary.

similar and related principles

case study hAtom

loosely related at best

The Start Simple consultancy service, presumably makes use of the pre-existing and broader generic principle of "start simple" which can be found referenced on numerous websites.

start as simple as possible was last modified: Wednesday, December 31st, 1969