An
AntiPattern.
DoTheSimplestThingThatCouldPossiblyWork is often misconstrued as this.
ItShouldSeemEasy. Why?
In the beginning, we though that structured design was easy: just make a stepwise decomposition of the program's function,
CodeAndYoureDone.
We thought that relational data base design was easy: just make a universal relations, find your dependencies,
CodeAndYoureDone.
We thought that object-oriented design was easy: just
FindTheObjects from the
RealWorld,
CodeAndYoureDone.
Playing jazz is easy. A few rules of harmony, learn a few patterns, pick up that horn and blow.
All these things should seem easy.
To a skilled practitioner they
are easy.
But, especially when you don't know how to do them,
when you have no examples and can't join in and learn by doing,
they're not.
So, we
DoTheMostComplexThingThatCouldPossiblyWork instead.
---
TheResidentCynic
It is obvious why people say that their design method makes things
simple; people want easy solutions and other people
want to provide them.
You are more likely to sell something if you claim it solves all the
problems of the world than you will if you are careful not to hype it.
If your idea is good, not hyping it means that people will miss the
benefits of using it. So, everything tends to be overhyped.
Overhyping a good idea has obvious bad consequences, but
has nothing to do with
DoTheMostComplexThingThatCouldPossiblyWork.
-
RalphJohnson
Is this page any different between DoTheSimplestThingThatCouldPossiblyWork? -- FrancisHwang
Yes, because it often takes work to go from the easiest thing to the simplest thing.
For example, copy-and-paste programming is easier to type than
OnceAndOnlyOnce, but
OnceAndOnlyOnce is simpler.
(quote moved to
TimeToMakeItShort)
I happen to agree that this is a VERY valid point. We have seen too many things go wrong because we took the 'easy' way out. But does simple mean easy or vice versa? There definatly has to be a corraspondence. I think it becomes more of an issue when refactoring. It is 'easy' not to refactor, or not to refactor everything that needs to be done. That would be where I see this 'easy' thing pop-up. -
AmrElssamadisy
The
FixTheProblem philosophy says that when you know there is a bug in shared code called by applications, you identify and fix the bug. What you DO NOT do is to write patches to the applications that might trigger the bug, thereby potentially crippling applications and leaving the bug for exploitation by newer applications that aren't aware of its existence. Specifically, this may mean to not
DoTheEasiestThingThatCouldPossiblyWork, if the patches are easier than actually fixing the source of the problem.