During the process of building software, you may find it necessary to draw the YAGNI card. For those unfamiliar with this acronym, it stands for You Aren't Going to Need It. YAGNI is a tool used to prioritize development resources. It asks the stakeholders whether a feature is a “necessity” or is just a “nice to have.” “Do you really need it?” is the operative question.

This simple acronym can also be used to control the effects of “premature optimization.” The malleable nature of application development can make it easy to spend countless resources on that last millisecond of performance when in all reality it wasn't really needed. How far should you go to wrest that last bit of performance out of your code? This question requires more questions. What is the schedule? How large is the dataset? How many transactions need to be processed within a given timeframe? What is the level of effort to achieve a desired performance metric? You will make countless judgment calls and with any luck end up with working code that is optimized to your current needs and no more.

You shipped your application with its just-good-enough baseline. Now what? As we all know, software spends much of its lifecycle in maintenance mode. Applications receive new features; have existing features modified; things thought needed are removed or refactored. The application may need optimization, either code or data.

Recently, the data optimization question affected my team. In late 2025, we started a project where we would be ingesting huge amounts of data (billions of records daily). This volume of data presented real challenges for our team. Most of our ingestion processes used a process like this:

  1. Download the data file(s) from Amazon S3 (or other data source)
  2. Open and transform the data
  3. Upload the data into S3
  4. Load data from S3 into our database

This process worked well for the files we had received up to that point. It simply would not work with the amount of data we would be receiving. We simply couldn't download, transform, and re-upload billions of records daily with this simple process. We experimented with numerous techniques but could not achieve performance that would work in production. Then we realized that we had the solution right in our face, and step 4 was the answer. We reframed our question. Can we just go from the S3 source straight into the database? Our code was already doing this with our files. Why couldn't it work with the vendor's data? This was the solution. We moved the raw data into scratch tables in our database and then did our transformations at the database level versus the code level. This was the first problem.

Once we had this amount of data, we needed to turn that data into actionable intelligence. We spent months building a new platform to handle this amount of data. We noticed our cloud computing costs rose higher than expected. We set up a meeting with our database vendor to discuss our escalating costs. They conducted an analysis and recommended using features and tools suited for our new data sizes. We reconstructed significant parts of our platform, adopting these recommendations, which resulted in a significant reduction of our computing costs.

Equipped with this knowledge, we spent the last three months rebuilding processes that had been in production for years. We adopted a different form of YAGNI. “You Are Going to Need It!” Any processes that could take advantage of these concepts were changed.

What wasn't a need then may now be a need. This is the duality of YAGNI. Embrace changing your frame of reference from aren't going to need to are going to need. Change is good.

And now for some news … there are big changes afoot at CODE Magazine. This will be my last editorial as editor-in-chief. I cannot say enough how much of an honor it has been to work with a team as great as this one. I have a lot of people to thank, so let's begin. First, I want to thank Markus Egger, publisher of the magazine. Markus gave me the opportunity to fill this role, and I am eternally grateful. I would like to thank editors Melanie Spiller and Erik Ruthruff. These two folks make our authors' good words great, and their support over the years has been essential. The magazine doesn't work without the back-office crew of Ellen Whitney, Tammy Ferguson, and Coleen Cade. Thanks for keeping the machinery running. Next, and it goes without saying, I would like to thank my authors; without authors, there is no magazine. Lastly, I would like to thank you, dear reader. When building the magazine, I always tried to put you first. As I step away, I would like to welcome CODE Magazine's new editor-in-chief, Otto Dobretsberger. Otto has been a long-time employee of EPS and a good friend. You are in capable hands.

Good luck and happy trails to you all!