In my old job, we had to switch away from our working but ancient Information System to SAP for similar reasons.
Spreadsheets are code. Their user-facing side is a particular form of livecode oriented around "sheets"/2D arrays of data tightly connected with reactive code -- which definitely has some legibility advantages -- but they're code.
Auditability is legibility. The advantages help. But also the reasons why Excel code is legible to auditors probably have some things in common with the reasons Ruby code is legible to devs who've worked with Ruby or sufficiently-Ruby like languages: exposure, training, and culture that have coalesced around it.
And I'd guess that people who don't understand that spreadsheets are code are less likely to be able to read the limits of legibility past where there be dragons, fog, and possibly even fraud.
Everybody knows it's code, I've written thousands of lines of code to back single spreadsheets. But the output is always a spreadsheet that people can flip through and check the calculations themselves if they like. It's code that outputs code. But is that a helpful observation?
I'm glad you apparently agree with my statements like "Their user-facing side is a particular form of livecode oriented around "sheets"/2D arrays of data tightly connected with reactive code -- which definitely has some legibility advantages," though that agreement does make it a bit strange to lead with "I don't think you get it."
> Everybody knows it's code
When someone enters the statement "Auditors understand and can check through Excel but they don't understand code" into the discussion -- or in other words saying that an Excel spreadsheet is not code (along with asserting that's why auditors can understand it) -- apparently not everyone does know this and so it's reasonable to reassert that a spreadsheet is made of code.
> people can flip through and check the calculations themselves if they like.
If, as in any other interpreter, they understand the spreadsheet code that's being interpreted and take the time to follow what it's doing. And that's one reason why the observation that spreadsheets are code can be helpful. The distinctive visual presentation and model of spreadsheets is a legibility convenience for sure, but it can also lull people into believing they're working with something less complex than code. It helps people keep in mind that what the spreadsheet appears to be doing may different from what it's actually doing, either because the complexity has pushed it beyond casual legibility (a common problem in all kinds of code), or perhaps because someone intentionally is using the full power of an interpreted functional reactive programming language (to say nothing of VBA macros) to intentionally hide some aspect of the spreadsheet's operations. It helps people keep in mind that whatever margin of accessibility Excel's affordances provide, it still requires some of the same kind of work to audit it that other forms of code would.
Excel supporting VBA macros blurs the lines but given that auditors spend so much time in Excel, they get to know that too. Now that Excel, has official support for Python, I suppose they'll need to have to come up to speed on that as well.
Um, what then is the point of an auditor?
Auditability is being able to back up what you claim with a record of some kind (receipt, purchase order, etc). Our QA group referred to this type of thing as "objective evidence". If your QA process says that you "shall have a design review", you need to prove that that review was held. In our case, our process said that minutes for that review had to be recorded. Our QA auditors would ask to see those minutes. Thank you ISO9001.
