YAGNI - Reaping the Benefits

People take different approaches to software, and we find that some of these work better for us than others. I'm a big fan of the YAGNI principle ("You Ain't Gonna Need It"), but historically it hasn't been much of a problem for me. But I came across an example of how it helped me recently -- even though I wasn't conscious of it at the time.

YAGNI: You Ain't Gonna Need It

The basic idea behind YAGNI is that we shouldn't code based on speculation of what we might need in the future. Business processes change, user needs change, and our software needs to change with it. If we build what we think we *might* need, odds are that we'll be wrong and that part of the software will remain unused. And that leaves us with code that is more difficult to navigate and debug without giving any benefit.

Historically, this has not been a big problem for me. My nature is as an under-abstractor. This means that I tend to lean away from abstraction. I add abstractions as I need them (and generally not before) because I've been burned by badly implemented abstractions that were put into an application "just in case".

So when we think about YAGNI, we think about the requirements that we have *now*. This doesn't mean that we don't think about the future; it just means that we don't build it yet. We should be thinking about the possibilities of our applications, and we should make sure that we don't code ourselves into a corner when we're writing them. But rather than adding the full abstraction (such as a plug-in architecture), we think about where we would put it if we needed it. Then we make sure that we leave a spot where we can add it later.

Making Things Easier

Old Application

One thing that I've been writing about recently is an application rewrite of my home automation software. Articles are collected here: Rewriting a Legacy Application. This is software that I've wanted to rewrite for a really long time, but I was too wrapped up in the complexities of the old application. There were a lot of features that had grown over the years, and it seemed like a daunting task to rewrite the whole thing.

So, I took a more practical approach: distilling things down to just the features that I actually needed -- the features that I used on a daily basis. This helped me create the requirements for a minimum viable product (MVP).

This process let me distill the entire application down to 3 features that I actually used. The other things (like UI, network access, and schedule editor) were all nice to have, but the more I thought about it, the more I figured that I didn't need them. For example, there's not much need for a UI. This application is always running on a machine in my house that's plugged into my TV, but I rarely look at the screen on that machine (it primarily just plays music and runs the lights while my TV does other things).

Rather than a huge, daunting task, this became fairly simple. In fact, I implemented the entire replacement in just a few days. Since then I've been refining it and adding new features, but that base replacement functionality went very quickly.

Leaving Room for Changing Priorities
So, I really took the YAGNI approach to most of the features in the old application. And that has turned out to be true. I've been running the software in production for a little over a month, and I haven't missed the features that I left out.

More importantly, I've been free to go in a different direction. The biggest example of that was when I added the ability to create schedule items relative to the current sunset or sunrise times. That original ugly code is in a much better state now (and it keeps getting better).

This code has been in production for a few weeks now. I currently have 2 items that are scheduled relative to sunset. A light in the living room goes on 30 minutes prior to sunset (when it's just starting to get dark), and a light in the bedroom goes on 1 hour after sunset. These are both ambient lights, and I've enjoyed watching them come on at different times as the days get longer. When I put the code in, the first light came on around 4:45 p.m., and now it comes on a little after 5:00 p.m.

But since the application is fairly "raw" as far as the architecture is concerned, I haven't committed to going in a particular direction. This has made it easy to implement this new feature (which had nothing to do with the old application). And I look forward to adding more features as I need them.

Wrap Up
So rather than getting bogged down in things I *might* need or I think I *should* need, I'm able to focus on the features that I *actually* need.

I do have some examples of where YAGNI has helped me in the past, but it's nice to see that the principle still helps me in my current coding activities -- even when I'm not consciously thinking about it.

For more information on YAGNI and other principles to help us with abstraction, check out the materials I have for Abstract Art: Getting Things "Just Right", including a Pluralsight course, slides, and a variety of blog articles.

Happy Coding!