solve-simpler-problems-first: Difference between revisions
(capture some thoughts) |
m (Replace <entry-title> with {{DISPLAYTITLE:}}) |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
{{DISPLAYTITLE: solve simpler problems first }} | |||
Part of the [[start-simple]] [[microformats]] [[principle]]. | |||
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 | == 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]] |
Latest revision as of 16:33, 18 July 2020
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.