Reminds me of "Ask HN: Is the world run by badly updated Excel sheets?" [0]
You need experience to see the shorcomings of spreadsheets. No version control. No tests. In general it's good for things that don't need to evolve, but stay the same (most likely because they're short lived).
[EDIT] An example of a comment from that thread pointing in this direction:
> In general, you adapt to the excel owner's quirks, not vice versa. If you don't like it you should create an excel sheet of your own and copy/paste, which people also do.
> I knew a project manager who's job seemed to be reconciling multiple versions of a spreadsheet with different authors.
Well yes, starting as a coder in the 2000s in the US, I always thought of my job as turning tortured spreadsheets sitting on a Windows network drive that have to be constantly babied by an underappreciated office staffer into web apps. But I do recognize that a lot of businesses have been run on spreadsheets and run well. There’s a scaling problem and when it hits, ideally you know and can move to an app, but perfect is the enemy of done.
You can use version control with Excel spreadsheets, though it's not very good. It's called "track changes" and even has a limited capacity to approve/reject changes from other people.
Very few people uses that feature, especially not the people who have built a Rube Goldberg machine to run their business processes, but you could do it if you wanted to.
That's not the only version control through - if you use Excel connected to Onedrive or Sharepoint (like most major orgs in my country), then you have version history built-in tracking every edit going back months.
The people who have "built a Rube Goldberg machine to run their business processes" should have used a database not a spreadsheet. Though they likely don't have enough training in database design and so if they had their result would be worse - but that is the fault of their lack of training. To be fair, database training is not something they should have in their position
It’s tricky because a lot of these spreadsheet “apps” are made when the business is young. Specifically non-tech companies who don’t have IT departments let alone any developers. They hire an MSP, get office, and go to town in Excel.
By the time they do get big enough to hire internal IT, the Rube Goldberg system is entrenched. Then by the time they get big enough again to need an internal dev team because off the shelf SaaS no longer cuts it, it’s too late. It’d take too many dev resources too much time and money to fix the spreadsheets, design databases, and start popping out web apps.
Plus the software development process is too rigid for how fast business requirements can change. The accounting department will just do it in Excel in an afternoon instead of being willing to wait 2+ weeks for the next sprint.
So we end up at a place in big enterprises where only some things get successfully moved to something more robust but there just isn’t enough resources (or will to allocate those resources) to tackle every spreadsheet, and so there are always key parts of the business that will forever run on Excel.
You can't track who changed what rows that way. Excel has native support for that.
If all you want is to see previous versions, just make the files read-only after saving them and increment a number in the file name every time you change something.
I've mostly seen the problem manifest when information is spread across a multitude of spreadsheets all stored in different places. The people involved don't know which spreadsheets contain what information and which are supposed to. Sometimes they end up having conflicting data purely because they don't realise that someone else thinks the primary source is spreadsheet A while they're only making changes to spreadsheet B.
Any flaws with Excel haven't been due to the actual program or data, but just how the files are managed within projects. Labyrinthian sharepoints, files being forgotten about on network storage, etc.
You need experience to see the shorcomings of spreadsheets. No version control. No tests. In general it's good for things that don't need to evolve, but stay the same (most likely because they're short lived).
[0] https://news.ycombinator.com/item?id=33611431
[EDIT] An example of a comment from that thread pointing in this direction:
> In general, you adapt to the excel owner's quirks, not vice versa. If you don't like it you should create an excel sheet of your own and copy/paste, which people also do.
> I knew a project manager who's job seemed to be reconciling multiple versions of a spreadsheet with different authors.