, because the satisfaction of having something work far outweighs any niggling complaints that whatever it does has no relationship to the task at hand. It is vitally important to understand that "work" means perform some action without obvious complaint.
is an important part of every worker's arsenal, because it allows the worker to truthfully claim that he or she "gets things done". It also, through sheer brute force or blind luck, can occasionally result in behavior that may be desirable or vaguely related to something that a customer somewhere might pay something for. In such cases, the work product in question can generally be sold to Microsoft for breathtaking sums of money.
The canonical example of DoTheFirstThingThatMightWork
is causing the string "Hello World" to appear somewhere visible to the developer or to a friend of the developer.
Not to be confused with DoTheSimplestThingThatCouldPossiblyWork
I disagree. It is exactly the same thing. From DoTheSimplestThingThatCouldPossiblyWork
So when I asked [KentBeck], "What's the simplest thing that could possibly work," I wasn't even sure. I wasn't asking, "What do you know would work?" I was asking, "What's possible? What is the simplest thing we could say in code, so that we'll be talking about something that's on the screen, instead of something that's ill-formed in our mind." I was saying, "Once we get something on the screen, we can look at it. If it needs to be more we can make it more.
He is exactly suggesting doing the first thing that might work. Once you've done it, then you can see whether it works, and go from there.
People have taken the idea of just getting something up on screen, i.e. WhatsTheSimplestThingThatCouldPossiblyWork?
, and turned it into a command, DoTheSimplestThingThatCouldPossiblyWork
, which is really just a platitude. Of course you should implement the simplest solution. Take the reverse: "Implement a solution that is more complex than you know you need." It's nonsense.
[No, getting something to work initially might involve algorithms, processes that are not the most simple, and need refactoring to make them less complex. You might aim to be simple initially, find it does not work, try different avenues till it does then realize it could be pruned. After doing so it would be the simplest that could possibly work, and settle on that, but it was not the first solution in your problem solving trajectory]
Read the quote again. Ward's point is to just get something
up on the screen. Anything, as long as it could possibly work. Once you have something on screen, you can start working on an improved solution. and serve as a starting point for an improved solution. The 'simplest' thing means the simplest/easiest to program, not the 'simplest solution'.
Think about why the phrase is 'could possibly work'. You think it's telling you to implement the 'simplest solution'. But then the phrase would be 'Do the simplest thing.', or 'Do the simplest thing that does
work.' However, the phrase is 'What's the simplest thing that could possibly
work?'. When you're thinking about a difficult problem, you don't know what definitely will or won't work -- you only know what could possibly work. Therefore, type the simplest-to-program thing-that-could-possibly-work, so you have tangible code to think about. That's what it's saying.
It's not telling you to strive toward some 'simple solution', even if that's a goal to aim for anyway.
Why do I get the feeling that there's a specific incident behind this? Come on, share with the group
There is a twenty-five year career of "specific incidents" behind this feeble attempt at irony. Quick -- name an O'Reilly book without
a "Hello World" example in it.
I get it ... DoesThisWork
"Not to be confused with DoTheSimplestThingThatCouldPossiblyWork
. - I disagree. It is exactly the same thing. From DoTheSimplestThingThatCouldPossiblyWork:
From my own work with the XP process, I feel that the "Simplest thing" is not, in fact, the "First thing".
The way I would put it is "Do the first really simple thing that you think might work". The first thing you think of is usually -not- simple. Ideally, you hash it out with your pair, or just roll it around in your head, strip of the kruft from the idea, and get it down to the simplest possible change to the code that actually seems to connect the dots. Next, write the first test for that, etc. You don't write any tests or any code until you've come up with an idea that's actually simple, and the simpler the better.
OK, I see what you mean.