Once you got used to it, honestly not really, other than needing Excel (not a huge deal since it was a Windows only application). I've no idea what the config parsing code looked like, but with the right library I doubt it was worse than any other non-trivial config parsing code. Mainly it just felt very wrong to my Unix, everything must be a text file, brain.

Well, xlsx is just a zipped dir of text (XML) files, so you can think of it as sort of following the .d pattern...

> the .d pattern

What's that? I ddg'd it and I got a bunch of hits for regex \d ...

conf.d, init.d

Ah, got it, thanks!

AKA "config directory".

See https://jmmv.dev/2020/08/config-files-vs-directories.html

That was an informative read - thank you!

There are some pretty awesome libraries for reading and working with Excel files - Aspose.Cells being one I used for years - basically a headless re-implementation of most of Excel usable via an API.

Never thought I'd get a chance to tell this story.

Early 1990s, college internship. The company did presentations for clients, like many do. They had an unusual way of presenting data that required using actual protractors to draw circles and curves, with pencil, on otherwise computer-generated charts. They read numbers from Excel spreadsheets and plotted them on paper.

I was shocked, to say the least. I proposed writing a program that read Excel spreadsheets and emitted the graphics. They loved the idea, especially from a summer intern.

So I wrote a letter to Microsoft asking for documentation of the Excel file format. A week later I got a thick envelope with a photocopied manual completely describing the format. I remember the word BIFF throughout. I wrote the program, it worked great, and I even negotiated a hefty lump-sum payment to sell it to them at the end of the summer.

It left me with a very positive impression of Microsoft as a developer-friendly company. Makes sense; developers are their platform's customers, and they're good at serving their customers.

For better or worse I created a very similar system, but using Google Sheets instead of Excel files and fetched with the GSheets API. In that case the configuration was gigantic (many of the configuration values were product-decisions, and it ran in hundreds of different environments with different tweaks), so the tabular structure made navigating things very natural. It also had the advantage of structurally highlighting how environments differed. Doing it with Google Sheets came with some extra nice benefits: online sharing, versioning, access control down to specific ranges, etc.

Basically every engineer who joined the team thought it was a unforgivable blemish on the system, yet it survived a few years with no major issues, long enough for the team to build an internal backoffice and port the whole sheet structure into a proper CRUD API.

Biggest downside I've discovered by doing this is that there's no great way to diff separate versions of one sheet. Best I've done is export to CSV and use a generic text diff.