solve simpler problems first

(Difference between revisions)

Jump to: navigation, search
(capture some thoughts)
Current revision (21:16, 1 June 2009) (view source)
(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]]

Current revision


Part of the start-simple microformats principle.

Start with:

Contents

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

solve simpler problems first was last modified: Monday, June 1st, 2009

Views