YAGNI stands for “You Ain’t Gonna Need It” (yet).   It’s a mnemonic meant to remind us developers not to speculate. That we should only put in code that addresses the task at hand and worry about tomorrow’s challenges tomorrow. There are many good reasons for this advice, the chief among them being that situations may change between the time that the speculative development happens and the need for the feature actually arises. In that case, the speculative development will turn out to have been wasted development time that could have been spent on addressing more immediate problems.

I thought I had learned this lesson years ago. I thought I was pretty sensitive to YAGNI and had a good track record for resisting it. But, recently I introduced a bug in a system that I was working on, and the ultimate reason for the bug is that I had committed the “crime” of speculative development.

Without going into too much detail, my error involved an aspect of website development known as browser caching. Programming to take browser caching into account is a balancing act. If you err on one side and force the browsers to cache too little, then the website bogs down and reacts slowly. On the other hand, if you err on the side of allowing the browsers to cache too much, then bad things happen with the site appearing out-of-date. It can be especially bad when one element of the web site that gets out-of-date is the style sheet that controls the site’s look and feel.

On a recent project, I thought I was being proactive, nipping this problem in the bud. I used a little trick that I had used before on other sites. The trick allowed the style sheet to stay cached for the most part, only forcing the browsers to reload the style sheet when we changed the build number (version number) of our software. It’s not that I was having any particular problems with cached style sheets at the time. I just thought I was being a good developer and applying my experience from those previous projects. Implementing that trick is just something that a good web developer knows to do, I thought.

Well, instead of preventing one potential problem, I actually caused a different problem — one that prevented users from logging in. Even worse, the login problem only manifested on the live server, not our testing servers, so you can imagine that this new problem showed up at a most inopportune time. Many users and fellow developers were inconvenienced during the time it took me to remove my speculative code and restore the ability for users to log in.

So, my lessons learned were:

1. To crank up my sensitivity to YAGNI even higher. To stop doing even the simplest speculations, even for things I am certain I’m going to need soon, because I might be wasting my time. That, instead, I should write up a ticket (or a “task” or “developer story” or whatever my team chooses to call such units of work at the time). This way the ticket will be discussed and  scheduled — only when it’s actually deemed necessary.
2. During the fire drill when my fellow developers got involved to help solve the login problem, and after it was revealed that my browser caching trick was the culprit, I learned from them that I had used an old trick. I had been unaware that there were better ways to handle that situation using the current project’s framework. So, another reason that I should have just written up a ticket instead of actually doing the speculative work, is that when the ticket got discussed I would have learned about the alternatives sooner.
3. The fact that the login problem only manifested on the live server and not on the test server means that the test server could have been set up better to do a more accurate job of emulating the live server. On the other hand, it can never be perfect, which goes back to the argument that systems should always remain as simple as possible, so that there’s less to test, and less to go wrong.
4. That I need to do more development work via pair-programming. One of the virtues of pair-programming is that pairing partners can help each other to resist adding YAGNI code.
5. In lieu of finding a pairing partner, I should have at least insisted on having my code reviewed. At the very least, I should have insisted that my team mates read over my checkin notices. I’m quite thorough when it comes to making sure my code checkins are atomic and well documented (for my own sanity in case I ever need to revisit a change that I made). So, it wouldn’t have been hard for a fellow developer to call me on the YAGNI, had they been monitoring my checkins closer.