YAGNI strikes out again. Perhaps I have a psychic ability to predict things that will be needed at the end of a cycle. I doubt it. Psychotic, perhaps...

Today, within the last two weeks prior to shipping our latest product, I got a new requirement. The change was actually simple, considering how late in the cycle it is (normally, stuff coming at this point is complex - that's not a psychic prediction, that's historical). It involved outputting a space somewhere if the value that should be there was blank. If this were shell, that would be completely trivial: ${SomeVar:- } But this isn't shell. It's perl interpreting some data.

Thankfully, I didn't know about YAGNI 15 months ago when I wrote the code that handled variable interpolation (posted here). I thought it would be fun, though hopefully useless, to have a syntax that was like shell. If I did "(SomeVar:- )", it would do the same as shell. I also added "(SomeVar:+blah)" and even "(SomeVar:/regexp/replace)" which was kinda like shell, but with a perl twist. (Shell can do glob-replacement with # and %, but you can't use regexp's with that.) I freely admit it: I was wrong. It was needed. Just not then.

About 3 or 4 months ago, about the time when we were supposed to be finishing the code (so we could test relatively stable code), we started using the regexp version. Today, I used the :- version. At neither point did we have the time available to do this - the schedules were/are too tight with late requirements. Alternative solutions would not have been so clean, easy, and fast (both on developer time and computing time, although only the former really counts for us). They would have involved code changes since we didn't need this ability yet, and those would have been way more error-prone.

Based on a consistant history (I've been in the same team for about 9 years), I can predict with annoyingly high certainty that we will continue to need highly flexible code that can do things at the end of a cycle that we don't need earlier. What that will precisely be, I don't know. But by ignoring the principle of YAGNI, I know that I'm getting my job done in a timely and reliable manner at the times where it matters. The features requested go in, with a lower cost of change, higher reliability, better self-documentation, and all other good software engineering principles followed. Just not YAGNI.

Part of the claim that YAGNI makes is that you won't necessarily know what the best way is to approach the problem until you actually have the problem. In these cases, I think I actually did have the best way to solve the problem coded well in advance, but I can buy the argument that this could have been fluke. However, the fact that I had written code to handle some generalised substitutions means that I had specific areas of the code (well, one area) to change should I need something a bit different. Slightly different syntax to get what I wanted, with a minimal impact to other code, and actually fairly small impact to that code, too. But the architecture was written and tested long ago, meaning only minor changes, if any, would be required now.

Does this mean I think YAGNI is a bad idea? Not necessarily. I just think it needs to be taken with a bit of salt. A bit more than the rule against goto's - which also should be ignored when appropriate. Sometimes, the prepatory work that goes into a feature that YAGNI would apply to will actually provide the flexibility or architecture to do what you really need to do when the time comes, with a much smaller investment in time at a point in the cycle where you can't afford large investments.

To be clear, when I wrote the features that I just started using, back in February of last year, my goal was to make the variable interpolation more flexible, and I chose what I thought was a cool way to test it: emulate some of the shell capabilities. I just didn't see a need to remove the test code since it was useful while I also hoped it wouldn't be needed (thus useless?). Even the flexibility itself wasn't needed at the time.

Sometimes, it's just good to have a tool in your toolkit, even though it's not needed. A screwdriver isn't needed if you have a hammer. Especially if you don't do any construction-type of work. But having them is probably still a good idea, just in case.