What Will This Become

The question is arguably the exact opposite of the XP principle "YouArentGonnaNeedIt", and it reminds me of one well-known instance where applying YAGNI may have been a mistake.

DonaldKnuth's TeX typesetting system is a wonderful thing, but many things one might want to do with it are (so it seems, anyway) unnecessarily painful. That's because its macro language is basically a complete, but very nasty, programming language. If Knuth had realized at the outset that TeX would have a Turing-complete programming language inside it, perhaps he'd have done it rather differently. (Apparently someone - might have been GuySteele - said to him at the outset, "You know, this thing is going to need a programming language", but he didn't believe it until it was too late...)

I think this serves as a salutary reminder that DoTheSimplestThingThatCouldPossiblyWork is only as good as your predictions of what could possibly work, and that even Very Clever People (like Knuth) sometimes get that wrong.

-- GarethMcCaughan

There is a tension between apparently opposing viewpoints in XP. On the one hand you have YAGNI, which if applied mindlessly says that you should not choose one architecture over another, one technology over another, one language over another before you start writing code because you're only making these choices in terms of ThingsYouMightNeed?. (Yeah, I know - the contradiction becomes obvious when you bring in the language. But how is the choice of a language much different from the choice of a technology?) On the other hand, YAGNI only goes so far, and no further. You need to make some initial choices. You are supposed to come up with a SystemMetaphor, at the least.

RonJeffries says that the point of XP is to keep the "vision" with the customer, and (I quote) to 'consciously separate programmers from visioneering'. But it's not, IMHO, the role of the Customer to come up with the right architectural choices; they are engineering decisions.

The way I look at it, though, is that choosing an existing technology (say XML/XSL in the discussion I'm quoting Ron from), or deciding up front that your system will need a programming language, might in fact be a way to fulfill a UserStory. Say you're considering XML/XSL for a Web site - you already know that the XML/XSL combo works well, that it provides separation of presentation and content, that it might be useful; you're just not sure that it is the "simplest thing". Turn the proposition on its head : think of a case where you know you're not going to need that technology. The example of Wiki comes to mind - there's so little "presentation" to deal with, and it cares so little about all content being formatted in a consistent way, that you wouldn't bother with XML/XSL.

That gives you your UserStory - "I want my site to have 'heavy' presentation, not just bold and italics, and I want content to be consistently formatted according to style." If you took the time to write CrcCards for this UserStory, you would probably come up with a Document class responsible for holding the content, and a Presentation class which displays it. But since you've already identified XML/XSL as having these roles, you don't have to bother writing the story, or doing the cards, or writing a spike solution; you know you have your answer and the UserStory is addressed. (To be complete you should have an AcceptanceTest - it consists of a sample XML document and a sample XSL stylesheet...)

Another way of looking at it is that a technological/architectural choice should be falsifiable, just as a scientific theory. You could very probably apply the same line of reasoning to a system for which you're considering the use of an embedded language. Can you think of a context where, most other things being equal, having an embedded language is obviously of no benefit? And then, using the things not equal as a guide, can you come up with an implicit UserStory that is satisfied by having it?

-- LaurentBossavit

Another way of putting it is that TeX suffered from a failure to refactor. It would be an interesting challenge to implement it in a way which made refactoring possible, but I am willing to believe that some jobs are intrinsically difficult to refactor. Eg having to keep compatible with existing end-user scripts would be a problem. In these circumstances, where the cost of change is very high, YAGNI doesn't apply and you must think ahead more, and get the design of the script language right before publishing it. -- DaveHarris