Do The Easiest Thing That Could Possibly Work

An AntiPattern. DoTheSimplestThingThatCouldPossiblyWork is often misconstrued as this.

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.