solve-simpler-problems-first: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(capture some thoughts)
 
(rewrote / expanded)
Line 1: Line 1:
<h1>solve simpler problems first</h1>
<entry-title> solve simpler problems first </entry-title>


One of several microformats [[principles]].
Part of the [[start-simple]] [[microformats]] [[principle]].


It's very hard to solve a hard problem by directly solving it, that is by trying to jump to designing (and/or building) a 100% solution to a hard problem.
Start with:


It is <em>much</em> easier to solve the "easy" or "common" 80% of a problem, and once that's been solved and implemented, you iterate (using the filter of the real world) and figure out what the next 80% is that "needs" solving (per real world needs, not hypothetical needs).
== simpler problems ==
Large problems can often be difficult to solve and may seem to require complex solutions.
 
The first step to creating a simple solution is starting with a simpler problem.
 
== parts of problems ==
One way to simplify a problem is to solve a part of the problem before attempting to solve the entire problem. Often the experience gained with solving a portion of the problem will illuminate other aspects of the problem and make them easier to solve.
 
== specific problem ==
Look for a problem to solve in a specific real world domain, rather than a broad set of domains.  When generic examples are given, ask for specific examples.
 
== immediate problem ==
Prefer addressing an immediate problem over a (often simply hypothetically perceived) longer term problem.
 
== the 80 percent ==
Look at solving perhaps the 80% of instances of real world (see related principle: [[humans-first]]) uses of that specific problem rather than trying to solve 100% of such use-cases.
 
It's very hard to solve a hard problem directly in its entirety, that is by trying to jump to designing (and/or building) a 100% solution to a hard problem.
 
It is <em>much</em> easier to solve the "easy" or "common" 80% of a problem, and once that's been solved and implemented, you iterate (using the filter of the real world) and figure out what the next 80% is that needs (per real world needs, not hypothetical needs) solving.  See [[start-simple]] for more on iteration.
 
Note also that the '''80% of [[examples]]''' refers to ''content'' being published (i.e. human content publishing behavior), not to ''syntax'' or ''explicit schema'', e.g. class names, other formats etc.  Which formats and names to consider re-using for microformats property names etc. is another part of the [[process]] and is described a bit in [[naming-principles]].
 
== related ==
* [[microformats]]
* [[start-simple]]
* [[principles]]
* [[humans-first]]
* [[process]]
* [[naming-principles]]

Revision as of 21:16, 1 June 2009

<entry-title> solve simpler problems first </entry-title>

Part of the start-simple microformats principle.

Start with:

simpler problems

Large problems can often be difficult to solve and may seem to require complex solutions.

The first step to creating a simple solution is starting with a simpler problem.

parts of problems

One way to simplify a problem is to solve a part of the problem before attempting to solve the entire problem. Often the experience gained with solving a portion of the problem will illuminate other aspects of the problem and make them easier to solve.

specific problem

Look for a problem to solve in a specific real world domain, rather than a broad set of domains. When generic examples are given, ask for specific examples.

immediate problem

Prefer addressing an immediate problem over a (often simply hypothetically perceived) longer term problem.

the 80 percent

Look at solving perhaps the 80% of instances of real world (see related principle: humans-first) uses of that specific problem rather than trying to solve 100% of such use-cases.

It's very hard to solve a hard problem directly in its entirety, that is by trying to jump to designing (and/or building) a 100% solution to a hard problem.

It is much easier to solve the "easy" or "common" 80% of a problem, and once that's been solved and implemented, you iterate (using the filter of the real world) and figure out what the next 80% is that needs (per real world needs, not hypothetical needs) solving. See start-simple for more on iteration.

Note also that the 80% of examples refers to content being published (i.e. human content publishing behavior), not to syntax or explicit schema, e.g. class names, other formats etc. Which formats and names to consider re-using for microformats property names etc. is another part of the process and is described a bit in naming-principles.

related