3

I recently came across to this principle and so far it is clear the fact that doing things that you don't need at the moment is not feasible as they might not be used or might be changed.

That being said, consider the following scenario: You're working on an application that needs to display text in labels, in several places/parts. The targeted language is English, and there is no requirement to implement multi-language. At this point, if you needed multi-language feature, you'd define every string in a resource file (let's say it's an XML file) and create/use a class to read them and assign them to the corresponding labels (according to the language). Thing is, since multi-language is not a requirement, YAGNI.

So, do you still define strings into a resource file and implement the reader, or you hard-code them and reafactor when you actually need it?

5
  • 1
    Hypotheticals like this tend not to fare well on Programmers. It's a mix of being too much "primarily opinion based" as well as "too broad" in that too many answers can address the question.
    – user53019
    Commented Jan 31, 2015 at 1:27
  • I'm not asking for opinions nor "what's the right way", I'm asking to explain YAGNI principle applied to this particular case Commented Jan 31, 2015 at 2:04
  • 3
    In your case, this is a 'strategic' question. It is a project-level question, it is a question for your customer or marketing department (if you are a vendor). There is no correct answer based on the provided info, or so I see.
    – NoChance
    Commented Jan 31, 2015 at 4:03
  • 1
    The good thing about YAGNI is the fact that you posted this question. It's a great subject to make a decision on with the team. Then it's a recorded decision that you do support multi language or you don't. It's in general not a decision you should make when you are implementing the texts. It's a decision you make in your meetings. Commented Jan 31, 2015 at 16:26
  • You use GNU's gettext which allows you to embed text in your code but can find and change them, even on the fly. gnu.org/software/gettext Commented Feb 9, 2015 at 15:57

4 Answers 4

8

Hard code and refactor when you need it. Time is money, yadda-yadda, is it worth the time/money to have the unused feature?

Also, it's not hard to do later as much as it is tedious. Pawn that task off to a junior developer when the need arises.

Finally, when the time comes, some automated tools may get you most of the way there. Such as Eclipse's string externalizer.

10
  • 3
    I down voted you because you're just assuming that every developer will take longer to develop the resource based version, which is a flawed assumption. A developer who has done the resources version many times before won't take any longer than just hard coding. Commented Jan 31, 2015 at 1:35
  • 5
    I disagree with @RibaldEddie in this scenario. The resource version (imo) adds quite a bit of complexity to your app for no (immediate) benefit. Though in general "the right way" provides benefit for no real cost.
    – Telastyn
    Commented Jan 31, 2015 at 2:30
  • 3
    @RibaldEddie: "A developer who has done the resources version many times before won't take any longer than just hard coding" - IMHO, that is a misconception. The additional efforts maybe low, but not zero, and they are less transparent. See my answer below.
    – Doc Brown
    Commented Jan 31, 2015 at 9:28
  • 1
    @RibaldEddie Actually YAGNI is about more than just the possibility that some feature you're planning may not be needed. Many developers add "yet" to the end of the phrase to highlight that it applies even to features that definitely will be needed. As well as reducing wasted effort, it's also about delaying architectural decisions in order to gain as much information about the system you're building as possible before implementing them...
    – Jules
    Commented Jan 31, 2015 at 13:17
  • 3
    I also think the notion that a hard coded value equates to coupling and therefore increased complexity is nonsense. Coupling is about the risk that changes in one module of your code will require consequential changes in another. Using a hard coded value of a language-provided type incurs no such risk.
    – Jules
    Commented Jan 31, 2015 at 13:22
6

Making applications multi-language does take some additional development effort. You can either invest that effort right from the start, every day a bit. Or you can invest that effort afterwards, when you have written >100K lines-of-code. Fact is, the sum of the needed efforts in both cases is not so very different as you might think.

The first approach actually disguises the needed effort which make some people believe the second approach is more costly, but IMHO that's a misconception. The second approach actually shows you the real costs and makes them much more transparent. And that is what the YAGNI principle is about: saving that hidden costs at the time you are not ready to invest it.

That said, providing applications for multi-language support right from the start might be the right strategic decision for lot of software products, especially when there is a good chance to sell those applications to a wider audience. But one should not believe that such a decision comes totally for free.

4

YAGNI is often in opposition to other established principles and/or best practices. Other examples include several of the SOLID principles, which are largely about structuring your code to make certain kinds of change easier in future. But what if you don't ever need to make those changes? Then the extra work involved in, say inverting the dependencies between two different parts of your application, and the extra complexity introduced by the unnecessary abstractions that such an inversion requires, is wasted.

YAGNI doesn't mean we should never do such things. It does mean we should stop to think before doing it and make a serious assessment of how much effort we're about to put in, how likely it is to pay off, and how much easier it is now than later.

In your example of externalizing strings, the amount of effort is small, but it is also not much harder to do it later, as Doc Brown has suggested. And you're the only one who knows how likely it is that you will need i18n support in the future.

Personally, I'm inclined to leave this particular task until it is necessary, but my experience is largely in building internal apps for SMEs that rarely need the facility, and I work with tools that have support for automatically refactoring to an external string resource. Your market and tools may be different, which might result in a different decision.

2

With just a few exceptions, code, data and configuration should be separated. Hard-coding is generally considered a bad practice. You should put UI text into separate file just so you know where to find it, not because you might need i18n. This will not take much longer than hard-coding, but maintainability will be better.

Also with external resource file you will be able to change text without rebuilding/redeploying an app. This may be the case for web apps, for example.

So, this is not breaking YAGNI, but just following other principles/practices.

3
  • 2
    "Also with external resource file you will be able to change text without rebuilding/redeploying an app." - You ain't gonna need that either. Your answer to me seems oblivious of actual YAGNI. Commented Jan 31, 2015 at 7:36
  • Yes, you might not need to edit resource files, but since it's just +2 mins of extra work, I believe it's not breaking YAGNI, which is about not implementing extra features. Having a resource file is not a feature, it's just a sane way of separating data from code. There's a phrase which I don't know a proper English equivalent of, which says "to save (money) on matches", meaning "trying to avoid minor tasks to save a bit of time/money/effort while wasting those resources on bigger scale". Not putting strings into resource file because of YAGNI is exactly it.
    – scriptin
    Commented Jan 31, 2015 at 12:29
  • 1
    The closest english equivalent to the phrase you reference is probably "penny wise, pound foolish", although I tend to put my faith more in the converse "look after the pennies and the pounds will look after themselves".
    – Jules
    Commented Jan 31, 2015 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.