Live data from Hacker News

Ditching Excel for Python in a legacy industry

amypeniston.com

171–180 of 289 posts

Re: Ditching Excel for Python in a legacy industry

#171
post #26

I'm a research actuary working in reinsurance. Here is why I think Python creates more problems than it solves from the standpoint of most insurance business users: 1.) Environment management. There are many solutions for managing python dependencies, my favorite is Docker + pip. Good luck getting actuaries and underwriters to write Dockerfiles etc, and good luck getting I.T. to support Docker on Windows desktops. Li…

I think these are all fair points and a good reflection of the downside of Python. But there are also some pretty huge upsides. My view is that for any model of significant complexity, the pros of Python outweigh the cons from a technical point of view.

- Abstraction. It's very difficult to effectively abstract parts of a model in Excel. It's a bit like a doctor having to 'model' a human being as a collection of atoms, rather than having abstractions like organs, cells etc. This makes it very hard to build re-usable components, so analysts end up reinventing the wheel. You also quickly hit a 'complexity ceiling' in Excel, above which mistakes and errors becoming much more likely, and complexity is very difficult to manage.

- Existing libraries provide a huge range of sophisticated calculations and operations for which we don't need to write any code.

- Separation of concerns - particularly separating data from model. Easy in Python, hard in Excel. Another aspect of this is that using data science software promotes the use of tidy data[0] (i.e. clear thinking about how data should be structured).

- Unit/integration tests. For complex models, these are essential. Users of Excel (even extremely clever/competent people) don't have have a great reputation for producing error-free spreadsheets, and I think this is an important reason why, alongside copy-paste errors. The tools for testing in Excel/VBA are rudimentary.

- Version control. This is particularly important for historical reproducibility because it allows us to run past models, and also understand what has changed in the codebase since.

I appreciate some of the above is also possible in VBA, but if you're writing an entire model in code and not really using Excel at all, my view is it's better to use a more sophisticated programming language.

There is also an important cultural point of having to re-skill everyone, and I can see that in some context that means in the short run at least, Excel/VBA may still be better overall.

I've written a bit more about all of this here: https://www.robinlinacre.com/transforming_analytical_functio...

[0] https://vita.had.co.nz/papers/tidy-data.pdf

Re: Ditching Excel for Python in a legacy industry

#173
post #47
post #43

Earlier quoted context omitted.

You could automatically import a table from the web into the sheet, or alternatively create some custom data types for currency conversion.

Or you could act like you're responsible for tens of millions of dollars and hand it over to someone who can make sure it doesn't blow up. "We don't need to hire an electrician to wire up the office, I did my garage using uninsulated wires and it works perfectly!"

The guys handling millions of dollars should be trained in finance / accounting, so they aren’t untrained.

Handing over to IT usually means their flexible spreadsheet that they can change as they require, turns into an expensive and inflexible black box that only IT can change and that doesn’t integrate with the rest of their decisions. Also the new solution also probably has errors and pulls currency info from the same endpoint. Excel isn’t perfect, but it’s used for a reason.

To use your analogy, You can wait for an electrician to change your lightbulb, but that means your going to be working in the dark for longer.

Re: Ditching Excel for Python in a legacy industry

#174
Lots of discussion here of Python and R as alternatives to Excel. But no mention of drag and drop data processing tools such as Alteryx, Knime or Easy Data Transform. Are these not a more natural alternative to Excel for people who don't have a programming background?

Re: Ditching Excel for Python in a legacy industry

#175
post #50

I'm pushing for our actuarial team to transition to more R + Git. After 3 years of preaching, most of the actuaries now use RStudio + git as their primary work tool. It is happening. What we did : 1) Provide documentation on everything from install to using internal R libraries for ETL. 2) Provide mostly problem free, always updated VMs with RStudio Server/ Shiny Server. 3) Establish an hotline channel for instant he…

The current top comment (sibling to the one I’m replying to) argues that keeping Python environments across actuaries/users computers up to date is too difficult.

This is nicely solved by using R server.

I’ve worked in an R server shop, and the experience is really nice. You log on to the server in chrome or Firefox and the browser window basically becomes RStudio and all calculations are done on the server and all code and data also lives on the server which is a huge bonus in terms of data protection. No copies are floating around on peoples laptops and if Johnny is sick and forgot to push his code to git - no worries, it’s all on the r studio server.

I don’t now of a nearly as good Python solution. I think Conda suggests using jupyter lab, and while that is a great environment it’s not great if it’s all you can use.

Re: Ditching Excel for Python in a legacy industry

#176
post #26

I'm a research actuary working in reinsurance. Here is why I think Python creates more problems than it solves from the standpoint of most insurance business users: 1.) Environment management. There are many solutions for managing python dependencies, my favorite is Docker + pip. Good luck getting actuaries and underwriters to write Dockerfiles etc, and good luck getting I.T. to support Docker on Windows desktops. Li…

Those are fair criticisms but I think under Windows, Docker+pip is the worse way of managing it

2 and 4 are surprising, it would be interesting to do a benchmark and maybe figure out the best way to do stuff in Python for your case

About 3, I suppose that's why developers should break up complex expressions (and not only in Python)

Re: Ditching Excel for Python in a legacy industry

#177

The author pretty accurately describes a business model for a startup in an enterprise company: offering a service that was once hidden in some excel sheets. As a developer at heart turned Senior Manager, I find this article especially interesting. I stumble a lot over complaints like these in the enterprise company I am working for and truth to be told, I voiced many of these before myself. Problems I see: - What is…

I agree. The article came across as a programmer griping about Excel and VBA, while praising his/her favorite tooling as the answer to some programmer-centric greivances.

Re: Ditching Excel for Python in a legacy industry

#178

Earlier quoted context omitted.

Hey fellow reinsurance actuary! I totally agree that Excel has its place in modeling, especially one-offs, and your criticisms make sense. That said, we have been moving a lot of our calculations to Python. We have had way too many rickety tools to move files or send emails (“first you open this spreadsheet and click this button, then you open this spreadsheet and click this button, then...”), and way too many versio…

Much like the referenced Excel spreadsheets becoming unwieldy, so does a dev's machine [0]. 0. https://xkcd.com/1987/

It would be considered incredibly bad practice for such a dev's machine to be used to perform almost any calculation of significant business importance. It's why mediocre Tech Executives are able to appear like they got some work done by focusing on "no access from dev to production."

With Excel there is no such separation, and when there is it would make a great punchline to an XKCD or Dilbert cartoon.

Re: Ditching Excel for Python in a legacy industry

#179

Earlier quoted context omitted.

It must be easier to build an auditable and reliable solution using a high-level language programming language and concepts like source control and automated testing. Excel is only easier if you aren't interested in building something auditable and reliable solution that might have some hope of being maintained after you have left the company.

That's the thing, most Excel workbooks start out as a one-off then gradually get adapted and extended until they're load-bearing. They're often built by specialists in another dept who definitely wouldn't consider themselves programmers. Doing it 'properly' would probably mean having to spec put the problem, get a budget, maybe wait a few months for someone to look at it. And the same thing every time the requirement…

And you find a bug that costs you $$$$,

I worked for a company that used an opaque excel spread sheet as a part of its accounting system - turns out there where bugs and we found a massive short fall one of the contributing factors in the collapse of the company.

Re: Ditching Excel for Python in a legacy industry

#180
post #16
post #5

As the author states - this is an issue for some really complex models - where the complexity, reusability and iteration challenges approach code. Most models do NOT take that many tabs, you can build a toy model near instantly - the production line from finished model and output to publishable material is a few shortcuts away. Having an analyst, write that same thing using Jupyter? From an accounts perspective? Man,…

"analysts" - lol! I know a HR director at a multi-national. He'd had enough of Excel and liked the look of this Python thing. I showed him R as well for balance but he wanted Python. I showed him how to install a Python distro and MS Code on his Windows machine, wired them up and off he went a few months back. The board are in awe of his presentations. He is not an IT bod at all but a Uni. degree in Psycho. involves…

And I have seen a board member not wanted anything but linear regression from his own data scientist team (If I remember well, they were like 5~ PHD or master in stats) because he couldn't understand anything. And that was in one of the largest organization in the world.
Post reply on HN