And now that it's a proper application they have to worry about authentication, down time, security, documentation, maintenance, and the customization and changes they could once do in an instant now requires filing a feature request, waiting for it to be implemented and deployed...

Even as a software developer I will freely admit that Excel is the right tool for many jobs. We shouldn't be so eager to transform workbooks into formal apps unless there is a really good reason to.

Excel is good for many things, but I'm not sure that complex financial models is one of them. Its convenience is balanced out by its lack of testing facilities. If you assume the industry standard of 1-5 bugs per 100 lines of code, you've got a huge liability on your hands.

Depending on what kind of firm or sector of the financial industry you're in, financial models have a problem of constantly changing. Web apps and other programmed solutions work well when you have to repeat the same model over and over, but they don't work well if you're constantly adjusting the model or changing its parameters/calculations.

In that case Excel's instant update and flexible (but quite powerful) formula scripting is often the best tool for the job because it means you remove the programmer middle man. I know some shops prefer to just teach the analysts how to write code.

Nearly every Excel wordbook I've ever reviewed has errors caused by updating a complicated model.

Often this is down to people adding/deleting/copying or modifying rows/columns and forgetting to change cell formula.

So, in theory you can modify a workbook and get instant results. In practice this seems to be nearly impossible to to get right.

Maybe that implies that we just need to start teaching analysts to write code, but the problem is that when you switch from spreadsheets to honest-to-goodness text-based code, you're just trading one set of problems (spreadsheet mistakes) for another (bugs in your code).

In the end I'm personally still in favor of Excel because it has a much gentler learning curve, though you are right that bulk operations in Excel are ripe territory for errors. I don't think it's "nearly impossible" though, it comes down to following best practices the same way you would in any programming language.

I only worked in finance for a brief time, but the operating procedure at my job was to formulate models in Excel, then validate them in a formal QA environment before using them in production.

I really doubt any major finance player allows someone to whip up a spreadsheet, plug some numbers in and start trading off that information. Excel is valuable in the early stages because it's fast, powerful and easy to collaborate in. Trying to eliminate it just because it's Excel is dogma.

> I really doubt any major finance player allows someone to ...

Clearly you only stayed in finance for a brief time :-)

Models have lower bugs.

Your fin model has normal sanity checks and then functional checks.

And in the end the out put must be readable AND make sense.

And whatever bug you have is going to propagate down your projected time series.

Finance chaps use finance as their weapon of debugging. Sure mistakes get through. I’ve seen mistakes get through code as well though.

Also - analysts get fired a lot faster.

IT and developers need to realize that they are expense generators not revenue generators in 99% of the companies.

IT's and developers' job is support revenue generation, not block it because IT or developers think they have a better way. In most cases IT does not and neither do developers.

Except excel is a generic solution. If you have to build a specific solution for each processes your costs skyrocket and people lose the ability to quickly implement something on their own. Everything takes forever to get done because you're constantly haggling with development and writing requirements instead of just opening excel and getting work done.

I've never seen two consistently created Excel workbooks. There is a lot of wheel inventing going on in the Excel world. It's possible that a more formal system would have less duplicated effort. It's also possible that doesn't matter.

"Everything takes forever because you have to write requirements" is a feature of software development. At the end you get software that does something that you (presumably) understand. Excel is a gold mine of undocumented terms, processes and functionality.

It's fast to build but don't pretend it gives any of the benefits of proper software development processes. The value proposition is in fact that it has none of those guarantees.

> There is a lot of wheel inventing going on in the Excel world.

There's usually more people who know Excel than people who can create systems. Meaning, the inefficiency is not that important. Some things just cannot wait or depend on a much smaller amount of people.

On the other hand I spent a lot of time as a data analyst explaining to business folks who "know excel" that their spreadsheets don't match because they used a different definition of week, or revenue.

Not really. In the long term, reg fines and dev costs balance out.

Citation please.

Pretty much every rogue trading scandal in the last few years is caused by some guy coming to the front office from the back and gaming the system with knowledge of its weaknesses. In more or less every case, poor front office controls, systems or data practices were identified as the root cause. Example https://www.google.co.uk/amp/s/amp.theguardian.com/business/...

And Lord knows software devs never implement poorly secured and/or buggy systems.

I work with engineers (mostly mechanical) who are in the same boat. We built a quick python app to do in ~30 seconds what their excel/VBA shit fest did in 45 minutes.

Excel and the like are better than nothing and for most non programmer numbers people probably fine - but if you need some real heavy lifting I would bring in the bug guns.

I like that -- Programming should be called a bug gun more often. How can we get more bugs in here, lets bring out the bug guns!!

Not saying that I don't believe you, but I've never seen a VBA code that executes longer than 1-2 minutes. What exactly does one do that takes so long?

copy the spreadsheet, modify some code because the need is sightly different (or the spreadsheet need adjustment) and voila. Either it works just fine on the first time, either you just begun a one hour debugging session.

To me excel is just fine, except when its not. A French bank lost 6 billion ten years ago because one market maker made false entry on a spreadsheat and no one in the back office noticed for more than 2 years. And the back office was not at fault here.

e.g. when reading in data one cell at a time instead of reading in a range at once. Basically inefficient programming. It's probably not that much about Python vs Excel but more difference in knowledge/expertise/capabilities.

As someone who works with these guys daily, you're 100% correct! The only thing that makes them change is new regulations telling them they have to.