"First, implement a new capability in the simplest way you can think of... Second, and this is critical to the rule, refactor the system to be the simplest possible code..."
This is always followed by a whole lot of explaining and confusion (See Do The Part Two). After all, why would I need to refactor if I already implemented the simplest thing in the first place? --Klaus Wuestefeld
It's the simplest way you can think of, so, somebody can find a simpler or better way to do it later. Besides, a lot of simple pieces of code put together start to be more complex, so you have to refactor to eliminate duplicated code and things like that. -- Daniel Munoz
Thank you for the explanation. That's my point. Explanations like yours would be unnecessary if we said "do the easiest thing first and then refactor" instead of "do the simplest thing first and then refactor!!?!". --Klaus Wuestefeld
First implement the simplest solution. Then refactor to make the solution clear and adhere to Once And Only Once.
A simple definition of "simple" is "few, small components". The DTSTTCPW quote says, "Do the thing that will work in the fewest, tiniest steps, then reduce the code to the fewest, tiniest pieces." But, yes, it's probably true that saying "easiest" is a better short-hand for "do the thing that will work in the fewest, tiniest steps".
We choose simple solutions first so that we can maintain focus on the customer's problem. Simple means easy to reason about. Easy serves as a synonym for simple so long as we remember that it is the thinking that should be easy. -- Ward Cunningham
Do the easiest thing that could possibly work, and then pound it into the simplest thing that could possibly work.
I think there is an important point in the terminology: Simplest != Easiest. Simple is difficult. (cf Mozart vs Rachmaninov and Saint-Exupery's quote "perfection is achieved when there is nothing more to remove). So it must be easiest first, I guess, and refactor to make it simpler -- Bill Weston
Look, just get it done and working; and worry about making it pretty and witty and wise afterwards.
And for the Cowboy Programmers out there, this is not to be confused with regarding simple elegant code as 'too complex' because it uses principles, techniques, and constructs that you have never bothered to learn (I meet a lot of folk to whom an untraceable 200-line hardcoded IF-THEN-ELSEIF/LOOP structure is regarded as "simple" while my replacement 3-line FOR EACH... DO ELSE loop is "complex and too hard to understand").
I believe there is a third type here - Minimal Design. A most minimalist design that solves the problem. However it is subjective as to how much of a Solving Design it is. it can be a short term or a long term solve. Take a problem like this. There are two user objects, totally separate from one another. You are asked to add a feature to them (lets for argument say it a single function). Do you a) add two functions to both objects implementing it inline (easiest?). b) follow a Once And Only Once rule and have both call a third common method (minimal design), or c) merge the concepts of the two user objects into a minimal, yet common design (simplest) or d) other gray mix of these options?
The simplest or easiest doesn't always constitute a long lasting solution. Simplest though is more refactorable and elegant, whereas simplest is not always easily changed. Easiest means you are deferring the need for refactoring later. Minimal is putting off simplest, but allowing some commonality. So simplest = shortest life-span, and simplest = longest life-span (I am making a handful of assumptions though, including the simple is a good design etc) I mean long lasting solve in the sense of how long it took before you need to alter or add to the code based on features or errors.
Then finally its how people view what is simple, easy or minimal. each term is subjective and 'time never tells' as there is not much data on any of this to quantify - Jonathan Crossland
I agree with that, and will add that in most cases such as this hypothetical one, each case/project/job is usually situational, so no one single approach/answer/solution fits all.
See original on c2.com 