6 ms·
no unit testing, but you can break your calculations up into reasonably understandable units where you can verify the output before incorporating that into a la
by Tagbert 4y ago
no unit testing, but you can break your calculations up into reasonably understandable units where you can verify the output before incorporating that into a larger formula. I frequently have hidden columns where I do parts of a calculation and then other columns that use those interim results for the final result. It does have overhead of more calculations but the payoff is fewer bugs and easier to verify in chunks.
- PaulHoule 4y agoA lot of that is discipline on the part of the operator. You run into the same problem with "data scientists" using Python or R who aren't familiar with software engineering practices. One thing I like about Excel is that it has a programming model that automatically solves dependencies on a graph so you don't need to tell it what order to compute things in, it just automatically updates the sheet when you change something. That would be such a useful facility to have for writing graphical user interfaces, in fact there are a few frameworks that are oriented that way https://mobx.js.org/README.html https://mobx.js.org/README.html One trouble I see with Excel is that there is not a clear separation between code and data which makes reuse hard. One area where "data scientists" get hung up is that they often think "I'm going to make the May 2022 sales report" or "I'm going to build the May 2022 language model" and don't really get that it not about making a report or making a model but rather making a system that can make the report or model for June 2022, July 2022, whatever.