0

At present moment, my desktop application operates purely on file names. That is, it parses file names and then reasons about the data contained therein. However, in the future, I see that there is a great possibility that I will bring in libraries which are capable of parsing file data, to improve my application for user experience.

By "at present moment", I mean that my app will likely operate on filenames for the first 3-6 months of its existence. I could write the code in a way where the app's functionality simply calls functions that operate on pieces of data within the filename directly. However, considering the possibility of operating on other data such as data from the filesystem, data within the file, etc... in the distant future, I have decided to create complex data structures now and have began building a simple database system, with most fields being None/NULL for the time being, but I'm storing these structures both on-disk and in-memory when the app loads.

Please note that performance is a top concern for me. At this time, I have a series of buttons in the UI and when pressed, actions occur at click-time. However, I've thought about beginning to have those actions occur asynchronously in the background while the user is using the application, and have the results of those actions stored (it won't take a ton of space).

Am I over-engineering this or are these wise design decisions to make at this time?

the_endian
  • 1,152

1 Answers1

3

Yes.

If you have to ask, the answer is almost always "yes".

tl;dr: YAGNI

Go review your prioritized list of feature requests, your roadmap. You don't have one? That's fine, write it as bullet points in a text file. Or create tickets in a github Issue tracker.

Now look at the next two or three items you will be implementing. Will you really need to refactor a ton of existing code to tackle those? Do you know now exactly what the new requirements will be then? If so, then surely you are more mystical and an even greater seer than Carnac the Magnificent.

Mortal engineers will prefer to largely put future concerns aside, and focus on building solid code for the currently required feature. Which includes unit tests, just in case you want to refactor later.

By the time the future rolls around, you will have more code committed to your source repo, and you will have a better understanding of what exactly the new use case requires. Wait until then. That's when you're gonna need it.

J_H
  • 6,742
  • +1 You cannot write code for future requirements, but you can write code that you can change with confidence - write tests. That's how you create a future proof codebase. – Greg Burghardt Nov 15 '23 at 19:35