Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finance Pros Say You’ll Have to Pry Excel Out of Their Cold, Dead Hands

wsj.com

Post reply on HN
Print view View original

141–150 of 317 posts

Re: Finance Pros Say You’ll Have to Pry Excel Out of Their Cold, Dead Hands

#141

Post by opportune »

djtriptych wrote: post #76
d--b wrote: post #66

Finance dev guy here. Excel's dominance in the field is because it is an _application container_ that _non_ dev people can use. The workflow is this: - old trader guy says to his junior guy: "hey can you look into xxx." - junior trader guy says: "sure I'll make a spreadsheet for it" - old trader guy: "great your model is all I need, let's trade" - several weeks later, IT guy says: "hey you're running a $100m book out…

I think pragmatic businesses that employ finance pros / quants are wise to include Excel as an essential part of their product development workflow. Excel is a great prototyping tool, and people are going to use it whether you want them to or not. These folks are motivated by money and don't give a shit about your tool if (they think) it costs them money (or time). Besides that, how many enterprise applications reall…

Ehh I doubt most quants are interacting much with Excel except when they need to work with non-quants. There's not much of a reason to use Excel when you could use something like Pandas instead, plus the Python libraries/environment will make everything non-tabled better to deal with anyway.

Re: Finance Pros Say You’ll Have to Pry Excel Out of Their Cold, Dead Hands

#142

Post by btilly »

d--b wrote: post #66

Finance dev guy here. Excel's dominance in the field is because it is an _application container_ that _non_ dev people can use. The workflow is this: - old trader guy says to his junior guy: "hey can you look into xxx." - junior trader guy says: "sure I'll make a spreadsheet for it" - old trader guy: "great your model is all I need, let's trade" - several weeks later, IT guy says: "hey you're running a $100m book out…

At a former job I had to build a reporting system. And had the trust to build it however I wanted. But it was my job to make it sufficiently useful that everyone would use it.

The smartest thing that I did was make it accessible from Excel. You could build a spreadsheet off of my report. Refresh the spreadsheet, the report ran, you got updated data.

I got essentially 100% adoption, and the rest of my job was spent finding people who needed data and adding it as an option to the reporting system.

Usually you expect a complex reporting system to have features like graphing, pivot tables, etc, etc, etc. My answer to all of that was, "You can already do that in Excel. I could spend a lot of time on it but I'm not going to do it as well as what you already have."

Re: Finance Pros Say You’ll Have to Pry Excel Out of Their Cold, Dead Hands

#143

Post by cm2187 »

d--b wrote: post #136
jimmcslim wrote: post #115

Earlier quoted context omitted.

> The issue is not how to get rid of Excel, it's how do we make a better spreadsheet... Or how do we better support custom tools integrating with Excel. Excel has a number of extensibility models... maybe too many; * VBA, * XLL add-ins (which is a C++ API, but check out the excellent Excel-DNA [1] which is a C# wrapper around this), * Visual Studio Tools for Office, which doesn't support the ability to implement your…

Better addins only means you get to do more stuff with Excel. Instead of doing one model, you may now be able to do a time series of models, or calculate The VaR (Value at Risk). There is no end to what people can ask from data. The only limitations are technological. And whatever extension you may have, your users will always push Excel to its limits.

I am a typical excel power user, and have started to increasingly do work outside of Excel (C# mostly). I find however that Excel is still a formidable GUI, particularly for tabular inputs.

One middle ground is libraries like SpreadsheetGear that give you a UI that has an almost perfect excel look and feel while giving you more control. You don't need to integrate your tool in Excel, you can integrate a quasi-Excel in your (.net) tool.

Re: Finance Pros Say You’ll Have to Pry Excel Out of Their Cold, Dead Hands

#144

Post by simooooo »

michaelmrose wrote: post #25
maxxxxx wrote: post #17

Earlier quoted context omitted.

I can see this in my company. IT has for some reason decided to put some data into Hadoop. Now the users need to write spec documents for each little thing and every trivial report takes months to get done. Before they had Excel and could create whatever they needed in minutes. Us programmers don't always make life easier for end users. Often we create a level of bureaucracy. EDIT: I like a lot of the responses here.…

Anything that can be done in minutes with Excel could be done in relatively short order via an actual programming language.

You ever tried to implement a generic pivot table builder? Good luck. See you in 2019

Re: Finance Pros Say You’ll Have to Pry Excel Out of Their Cold, Dead Hands

#145

Post by agar »

d--b wrote: post #135
codingdave wrote: post #98

Earlier quoted context omitted.

Excel is old-school Business Intelligence. We don't need to make a better spreadsheet, we need to make a better toolkit for data-driven decisions. There is very little reason that all users need to engage with their data in a grid of cells. When BI tools are as usable and flexible as Excel, that is when Excel will dwindle.

I'm not saying we should make a better grid of cells, I'm saying we should make a better application container that non-dev people can use. The big grid of cells is the weakest part of Excel by far!

People have tried to improve on that big grid of cells since VisiCalc in 1979. Considering it's the weakest part, it has been remarkably difficult to find something better.

As someone that spent years being buried in complex spreadsheets for hours a day (and supported and trained others who spent literally 12 hours a day building models), I can't think of a better combination of functionality, capability, and usability than that big grid of cells.

Re: Finance Pros Say You’ll Have to Pry Excel Out of Their Cold, Dead Hands

#146

Post by throwaway613834 »

dmurray wrote: post #107
frgtpsswrdlame wrote: post #59

Earlier quoted context omitted.

What? Excel handles decimals just fine.

It's an amazingly pervasive myth taught in CS 101 courses that "you should never use floating point types for currencies, or you might go to jail". In reality floats are fine for most financial applications, and for almost all those that would find themselves in a spreadsheet.

> It's an amazingly pervasive myth taught in CS 101 courses that "you should never use floating point types for currencies, or you might go to jail". In reality floats are fine for most financial applications, and for almost all those that would find themselves in a spreadsheet.

What do you think about this then? https://www.journalofaccountancy.com/issues/2014/mar/excel-c...

Re: Finance Pros Say You’ll Have to Pry Excel Out of Their Cold, Dead Hands

#147

Post by simooooo »

chadgeidel wrote: post #118
endorphone wrote: post #69

Earlier quoted context omitted.

The same excel workbook that let's the traders do their job would take months / years to convert to a web app Simply taking an Excel workbook -- even data connected -- and using that as the requirements that drive an implementation would be extremely quick and speedy, the result having a litany of advantages. But that's never how such projects go. Instead everyone has to greenfield some idealized pinnacle product.

I don't know your background but "taking an Excel workbook and using that as requirements to drive an implementation" is not speedy. I've done this several times in my career and it's very, very difficult. Not because there is any "idealization", but because the reason the spreadsheet works is because a human is doing half of the work . These spreadsheets are not some "hello world" easy to understand product - they a…

Currently web-ifying a huge pivot table (30+ columns) into a dynamic library SQL report for access via the web. It's a nightmare of horribly complicated aggregate grouping/totalling across many columns.

Additionally the original excel sheet made incorrect assumptions, resulting in a re-specification/design of what all the totals actually count.

NOT speedy.

Re: Finance Pros Say You’ll Have to Pry Excel Out of Their Cold, Dead Hands

#148

Post by throw_away54321 »

triplee wrote: post #6
osullivj wrote: post #2

Yes - Excel is deeply embedded in actuarial modelling.

Modeling yes, which makes sense given that it's a tabular math tool. Using it to handle all the pricing structure for a few thousand clients on the other hand is another issue by having underwriters plug in values that they got from an online application, though, not so much.

This sounds familiar...

Re: Finance Pros Say You’ll Have to Pry Excel Out of Their Cold, Dead Hands

#149

Post by agar »

chasedehan wrote: post #110
barrkel wrote: post #38

Earlier quoted context omitted.

Adding a new screen to capture information? With a nice graph to display for output? Does it conform to your UI style guide? Does it have passing unit tests? Is it integration tested? Is it code reviewed? Any migrations necessary? Any business continuity ramifications? Etc. Engineering has overhead otherwise it's just a bunch of cowboys that are no better than Excel hackers - and probably worse, because they have a l…

Does your '=vlookup(x, ...)' have tests surrounding it? How about code review? How about source control?

Actually, in my experience "sanity checks" were very often built into financial models.

Does your balance sheet balance? That's a pretty basic "unit test".

Do your calculated values match the financial statements values? No? Throw an error.

Divide by zero? Reference a blank cell (similar to an unset variable)? Using a value as a number? Referencing outside of a range? All immediately throw an error that will flow through your model.

And code review often does take place - in banking at least, models written by analysts are checked by associates and then VPs. People who understand what the numbers should look like can spot mistakes pretty quickly using a TI calculator.

Source control is a problem, but many models are one-offs for specific projects - no company (or deal) is structured identically.

You're identifying problems that have, for the most part, already been solved. Not perfectly, but in ways that work well within the structures that have been built around the use of Excel as a core tool.

Re: Finance Pros Say You’ll Have to Pry Excel Out of Their Cold, Dead Hands

#150

Post by Declanomous »

agar wrote: post #140
Declanomous wrote: post #112

Earlier quoted context omitted.

Or it could be like the place I worked where IT made as many hurdles as possible to the installation of new software. So I, as a database marketing associate, linked 4 different CRMs used by different departments together using the magic of Access, Excel and VBA. IT found out when they disabled a library (DAO) because "cryptolockers" could use it, only to break almost every single process at my organization. The IT d…

Version control in Excel VBA is easy. Just do a Save As..."Mission Critical Finance Model v2.xlsm", then "Mission Critical Finance Model v3.xlsm", then "Mission Critical Finance Model v3a (temp with changes for Jim).xlsm" and then "Mission Critical Finance Model v4 (maybe-trying to merge 3a back-DO NOT USE).xlsm" and so on...

That's true. Good luck doing anything with that though.

My main database was up to version 2051 by the time I left.

The class I have nightmares about is the "compile and backup" class I wrote, that decompiled the database, appended the date to each file, compared all of the non-data and non-binary components, recompiled the database with the most recent versions, and then made sure every database was linked to the most recent versions of other databases.

Why did I decompile everything? Well I learned that unless the file size changed markedly, the deduplication feature of the file replication system that our company used assumed the files were the same. Well Access databases can stay the same size for a long time unless you run a compact and repair on them. So I lost several weeks of work more than once because the system decided that an older version and a newer version of a database were the same.

Without that stupid "feature" I would have just had the production Access file be named Access-prod.accdb and updated it each day.

I honestly have so many nightmares about that job I'm intentionally doing easy work until I can convince myself that files don't magically delete themselves without a trace and administrators aren't deliberately evil.

Post reply on HN