[kwhitefoot]

> when somebody sends me a spreadsheet with functionality I've never seen before it's extremely easy to figure out what they did a

You must have encountered only very simple spreadsheets. I've had to reverse engineer a number of technical spreadsheets that took days of full time sweated effort to merely understand the principles and more days again to extract the methods accurately enough so that they could be reimplemented in a programming language.

[feoren]

Think about how much harder it would be if you couldn't see the inputs, code, and outputs all together at once. The difficulty you found has little to do with Excel; you were trying to learn a whole new domain by reverse-engineering a model created by an SME. Of course it took multiple days of effort to merely(!?) "understand the principles" of a brand new technical domain. Ideally the SME should be explaining those things to you as well.

[mlatu]

> The difficulty you found has little to do with Excel;

i claim, if you allowed access to an underlying source code representation of the spreadsheet, or rather, if you made that transformation at all, you could easily add symbols and labels to transform an excel sheet into something a programmer could turn into a binary but i doubt that step inbetween is desired

I mean, the activity of analyzing an excel spreadsheet is more akin to learning where all the items in your favourite point and click adventure is and in what order to get them where, than to actually analyzing a problem

[listenallyall]

When you've done that, is it all of a sudden super-simple? You've had to incorporate all the same complexity into your model. If you sent it back to a spreadsheet user, don't you think they would say the same thing, just backwards?: "I had to reverse engineer a number of technical data processes in R that took days merely to understand the principles..."

[kwhitefoot]

Perhaps not super simple but it will have been broken down into named parts. In the days before spreadsheets were as capable as they are now I worked with plenty of quite old engineers who would write Fortran instead; their Fortran was always better than the spreadsheets that they later produced.

[listenallyall]

The degree something is well-designed and comprehensible is based mostly on the developer, not the tool. A spreadsheet with named ranges/tables, cell comments (sparsely, where necessary), clearly-defined tabs, etc can make debugging or reverse-engineering a breeze. The visual aspect of Excel can also help debugging immensely, i.e. conditional formatting of cells failing validation, filtering to isolate subsets of data, etc.

I will certainly agree that it is quite rare to come across a spreadsheet that is perfectly-organized, on the other hand a ton of developers write horrible spaghetti-code too. Further, a 10+ year-old spreadsheet will open right up in Excel... while a 10+ year-old data project is often written in a language you've never used before (or hoped you'd never use again).