Probably Are Gonna Need It (PAGNI)

YAGNI

Software engineers like acronyms. It makes it easy to remember and refer to certain ideas. You’ve likely heard the acronym YAGNI, which stands for “You Ain’t Gonna Need It.” The premise behind this is that as software engineers, we have a tendency to overengineer things. We often add features that we think we’ll need and then they never end up getting used. Applying YAGNI means basically means don’t add any feature until you are 100% sure that you need it. No premature optimization.

Adding extra unneeded features is problematic for several reasons. First of all it takes longer to write, because we are simply writing more code. Because there is more code, our code is more complicated and harder to understand and reason about. Often these features add in a bunch of special cases and conditional logic. This can cause our code to run slower. It can also make us more like to introduce bugs. Each additional line of code also increases our testing and verification burden.

PAGNI

YAGNI is a pretty well-known and fairly respected concept, but I read 2 articles recently that made me question how widely one should apply the concept.

PAGNI is the idea that you “Probably Are Gonna Need It”. It is not exactly anti-YAGNI, but the idea is that while avoiding premature optimization is a good idea in general, there are some things that you just always end up needing anyway. It also acknowledges that some things are just harder to add after that fact. So PAGNI holds that things that you are highly likely to need and which are easier to implement now rather than later, should just be implemented from the beginning.

I took a DSH Workshop at GDevcon. Fab led an exercise where we talked about some of the things that you always need in an application or that you always end up adding, regardless of whether the customer requests them or not. We also do this exercise in our DQMH workshops. Fab put together the original content for those workshops so that is not too surprising.

Adding meta data to tdms headers is something that is quick and easy to do. It is something that you are “Probably Are Gonna Need It” (PAGNI).

Here is a common list:

  • Versioning – You always want to version your programs and display it to your users. The makes it easy to reproduce bugs. It also prevents you from trying to fix a bug that may already be resolved in a newer version. You should also consider versioning any file formats or APIs as well. You may never need it, but if you do, it is very hard to add after the fact and adding it is generally trivial.
  • Logging – This is always useful for troubleshooting. It’s almost always worth adding timestamps to these too. Again hard to do after the fact.
  • Metadata for datafiles – If you are collecting data in tdms files, it is very easy to add extra metadata. I wrote a free toolkit to make it dead simple. This is something that is very hard to add after the fact.
  • Configuration – You always need to take some configuration input from users. So incorporating a configuration editor screen from the beginning is probably a good idea.
  • Auto-generating config files with default values – If you have ever gotten a call where a customer had accidentally deleted a necessary config file or introduced some sort of typo or invalid entry, you’ll see the value in this. The solution is to have the code simply recreate the config file with sensible default values if it can’t find it. So if the file gets corrupted, you just tell the customer to rename it. The next time they run the program, it won’t find the file so it will generate a file with default values. They can then compare the two files and see where they went wrong.
  • Constants in config files – Almost everywhere I drop a constant, I almost always end up moving it into a configuration file. It saves me from having to rebuild the application later when the customer changes their mind, which always seems to happen. In this case having the configuration screen setup early makes this very easy.
  • HW Test Panel – The first thing I do for any hardware project is to create a hardware test panel. This let’s the technicians ring out all the connections and make sure everything is hooked up correctly, so I’m not wondering why my software is not working only to find out some sensor is not connected correctly. It’s also useful for troubleshooting problems once the system is deployed.

2 Comments on “Probably Are Gonna Need It (PAGNI)

  1. Lots of great ideas there, Sam. I’m a big fan of PAGNI, though I hadn’t put an acronym to it yet. As you say, YAGNI is a valuable paradigm, but applying it, like anything, requires consideration of the particular situation rather than adherence to dogma. I find that PAGNI is especially valuable in code that gets deployed more than once: re-use code, frameworks, utilities, etc.
    I like your idea about auto-creation of the config file. My particular twist, though, is that every time the program is run, I append a time/date stamp to the config file name and copy it to the data directory. That not only archives how the program was configured when they acquired the data, but it provides easy backups to address the situation you describe. If the config file is ever lost or corrupted, they can just copy a recent one from the data folder and rename it. Having your auto-created defaults file provides yet one more level of protection, in case they don’t have access to any copies in the data folder. I’d just be careful to make sure to alert the user that the defaults are being used.
    I read the tip about moving every constant to the config file years ago in the “Component Oriented Design” book (which I really liked – lots of OOP-like ideas before OOP was available in LV). I think the concept is good, but perhaps a bit overstated. There are TONS of constants all over my diagrams, many of which just don’t deserve the extra work of being put in the config file.
    I love the Hardware Test Panel idea too. Something I tend to do, but haven’t formalized it in my mind as clearly as you did.
    Thanks!
    DaveT

    • Glad you like it Dave!

      I like copying the config files to the data directory. I often add the config data ot the tdms headers, but that doesn’t easily facilitate restoring the config. And the alert idea is really useful as well.

      Steve’s book is one of my favorites. He says he doesn’t do OOP, He does just not with actual LV objects. As to putting constants in the config file, there are obviously some that will never change. Those don’t need to be in a config file. For the ones that will change it is worth considering, how likely it is to change and if changing that value would merit rebuilding the executable?

Leave a Reply

Your email address will not be published. Required fields are marked *

*