Opposite of YAGNI

There’s a motto in agile software development that says “You aren’t going to need it,” YAGNI. The idea is that when you’re tempted to write some code based on speculation of future use, don’t do it. (I go into this a little deeper here.)

Although “you aren’t going to need it” is a good principle for writing code, the analogous principle “you aren’t going to need to understand it” doesn’t seem to hold. When I’ve try to avoid understanding things in detail, I end up needing to understand the details anyway and wished I’d done so sooner. This has been my experience in math research, software development, and project management.

Obviously you can’t understand everything about everything, and some things you clearly need to know well. In the fuzzy area in between, especially when I’ve said to myself “I hope I don’t have to dig into this,” I’ve often regretted postponing the dig.

Related posts:

Opening black boxes
Why programmers write unneeded code
In defense of reinventing wheels

3 thoughts on “Opposite of YAGNI

  1. My take on why they say that is for inexperienced programmers who create a lot of architecture for simple features. They then either don’t end up using 80% of the architecture and 3 bad things happen.

    First, if a problem occurs, you have a lot of code to wade through, some of which is un-used kruft which complicates finding exactly where the error occurred.

    Second, you now have more code to maintain, and most of that code isn’t even used.

    Third, when it comes time to refactor, you have a lot of code to refactor for just a simple feature.

    While more complex than that, those 3 reasons cover 90% of what I’ve seen. While I get what you’re saying, especially from a low-D on Meyers Briggs, it doesn’t have to do with thinking. You and I both know we need a login form, so we build one with a username and password text fields with a submit button. That will work, and allow the user to get into the application with a valid session as well as verify our user story passes. ANYTHING ELSE added to that is kruft, and does NOT need to be built.

    Time and time again, I see developers building things that have nothing to do with logging in, like a remember me checkbox, multiple-login attempts via a timer inside the login service in case of network issues, mock classes to emulate the session in case we can’t do integration testing for awhile, etc.

    All of those things are valid features. All of those things are not needed, at all, to login.

    If you’re having to spend copious amounts of time thinking about a feature it’s (A) too big of a feature and needs to be broken down into manageable chunks (B) it’s just hard, and “thinking” and prototyping code algorithms for a solutions is a far cry from ignoring YAGNI or (C) it’s Trig and you’re stupid like me.

  2. This reminds me of the rule of thumb that the bug is where you want least to look for it.

  3. Actually, in busy production environments where I’ve been for some time, as others dither over ‘understanding’ a problem, I quite often come in and simply fix it. And then explain to them “fix it first, understand it later.”

    Of course, my ‘fixing’ it presupposes a good deal of understanding to begin with. Often it’s the case, that what you need to do first is keep things running and then later you’ll have the time to figure out this particular variant of that particular class of problems. But that presupposes good followup which can’t be assumed for all people.

Comments are closed.