I think the advice got turned into a command: "Do the simplest thing that could possibly work." [...] But as soon as it becomes a command, then we have to analyze it and ask, "Is that the simplest?" And all of a sudden it becomes complicated. What is or isn't simple?

So for you, Ward, it's a technique, not a guiding principle. I think that's a huge distinction.

In programming, a lot of simplicity comes from knowing what matters and what doesn't matter.

So there is an art to knowing where things should be checked and making sure that the program fails fast if you make a mistake.

It seems like you're saying that good/experienced developers really do make a difference when it comes to the balance between simplicity and complexity. I really like to hear this coming from someone with loads of credibility in the industry. Many methodologies are focused on making average and below-average developers productive. It's no secret that the productivity of the best programmers can outpace the mediocre ones by orders of magnitude. What seems to be said less often is that the quality of their work is higher too.

The value of experience is far too often ignored in this business.

I think the strategy described is more-or-less a "just do it" kind of thing, which is valid, but I think it is critical that developers understand the notion of refactoring in this context. Unless the atmosphere and attitude is one in which programs are constantly being refactored, this strategy can easily degrade into "whatever works" (today).

I often inherit the code of others. If the others' code is well-factored (simple?), then I can understand it quickly, fix defects, add features, enhance it, optimize it, whatever. But if the code is not well-factored, I face "difficulties" instead of savoring problems.

So, "the simplest thing that could work" should probably not be an end state, unless one considers "the simplest thing" to be the one that is most comprehensible to the next coder. And I don't get the sense from the article that that was what Ward had in mind when he coined the phrase.

Maybe I'm missing his point, but for me "the simplest thing" can sometimes takes months at which to arrive (after several rounds of refactorings and sometimes entire rewrites).

I wish the waters were not so muddy.

I loved this article and I'm going to print it out so other developers here can read it every time they get stuck! I'm the developer here everyone hates because I always ask why? why is that so complicated and why not just code it, I think I work in a simplistic way because everyone understands my code, I can write complex code that even I won't understand a week later, it is fun but counter productive ;-)

I'd like the idea of just coding it, then you can try understand it and maybe refactor it.

-Craig

A friend of mine once said that there are problems and there are difficulties. A problem is something you savor. You say, "Well that's an interesting problem. Let me think about that problem a while." You enjoy thinking about it, because when you find the solution to the problem, it's enlightening.

I personally prefer the word "challenge" over the word "problem" when used in the way that Ward Cunningham refers to it. "Problem" can mean "challenge", but it can also mean "difficulty". Like when one says, "that's no problem", they mean that there is no difficulty in accomplishing something, not that there is no challenge.

When you are stuck, it makes sense to try the very simplest thing that might possibly work as a sort of stub. When you know what you are doing because this is the 217th program you've written against this particular database or whatever, you know the API, you know the data, and you know your customers, and you need a special program for a special purpose, you code it right the first time.

For code that goes into production, you need to make sure you haven't left in any of these partial solutions. One way is never to write any code that you are not totally sure of. Testing, of course, is also required. When the cost of error is loss of human life or firing weapons or crashing the stock market, you might not want to pepper your code with syntactically correct code that "nearly works". And there is a point of view that we should code everything as if human life depended on it, since we see that there is so much software failure out there.

As a side note, it is interesting that there is no other area of human effort, besides software development, where the practitioners spend so much time and effort trying to figure out how to think about their work.

Ward wrote "I'm not a fan of checking arguments."

The best example I know of checking and not checking arguments is a dot product function, say dotProd(x,y). What doesn't have to be checked--and shouldn't be checked--is that x and y are 1) sub-scripted sequences and 2) the elements are numbers, not characters, etc. If either is not true, then there will be run time errors. Hence, checking is unnecessary and will slightly bloat the function. But what MUST be checked is that the lengths of x and y are the same. If that is not true, then the function may return a number that makes no sense. This will be a hard-to-track-down-bug.

So "yes" and "no" to the necessity of checking arguments.