111–120 of 317 posts
Earlier quoted context omitted.
With Excel any reasonably capable business analyst can do sophisticated calculations quickly without needing anything else. With a web app, SQL database and whatever the ramp up cost is huge in comparison.
The ramp up cost isn't months vs minutes. That is just pure nonsense.
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…
Where I work, we get to the part IT guy part, and then the quote comes out to be like $200k+ (and 6 months) to duplicate a SAS program, Excel spreadsheet, or Access database that an analyst hacked together in their spare time.
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 director was pissed, but he had to reenable the library because everything ground to a halt.
Bonus points: he told my boss that VBA macros were bad because hackers could use them to take over the mouse and click on things.(Edit: I also distinctly remember the IT director accusing me of being a hacker when he found out I was using VBA.)
I still wake up in a cold sweat with nightmares that something broke in that system. The VBA editor in Office is an absolute nightmare when it comes to debugging. No version control either.
Earlier quoted context omitted.
Well, if you are taking many hours to process said data on a single processor machine (say eight cores) then throwing it into an environment where you can crunch it with many cores (say 1440) then this does make some kind of sense. Also putting the data into a secured multi user environment with redundancy and also business continuity. as opposed to fecking sharepoint
Sharepoint is where good information goes to die. It's a write only wiki - you put stuff in and you can never find it again.
Earlier quoted context omitted.
Have you ever been a power user of Microsoft Excel? And then tried to replicate that functionality in Google Sheets? Or is your aversion mostly to the M- word? I find it funny that when it comes to vi vs emacs (or any such similarly geek-approved thing), fans of each will jump up in arms about the precise reason their platform is better, but the same kind of people would not want to take hundreds of thousands of busi…
Probably because the geeks can consider the virtues of making a spreadsheet vs an application while the office workers are incapable of understanding more than half the equation. Also office workers can't always be trusted to even plug things in let alone properly assess what an optimal solution looks like.
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…
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 own custom functions (e.g. =MyAddIn.GetStockPrice() unlike the previous two options, and
* The more recent 'Apps for Office' extensibility model across the whole Office suite, which is basically an embedded web browser instance in your Office app which gets a Javascript API for interacting with your Office document. This is also getting custom functions support in Excel [2]
At the energy consultancy I work for we have built a suite of Excel add-ins that allow analysts to get the data that they want easily into their sheets, but don't impose any (unreasonable) restrictions on how they work with the data.
[1] https://excel-dna.net/ [2] https://dev.office.com/docs/add-ins/excel/custom-functions-o...
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.
> we need to make a better toolkit for data-driven decisions Why? Excel is ubiquitous, powerful, and accessible. It only really falls apart for huge data sets -- at which point you build a cluster and feed the output back into Excel anyway. I'll never understand why software engineers feel like everybody else is a caveman banging rocks together. Excel replacements are a hard sell because, by and large, they're not ne…
I work on a desk which has a lot of vital calculations in Excel spreadsheets. They work, and we make money, but it takes a lot of human effort (expensive trader effort!) to keep them working properly. If we want to scale up - more people, more products, etc - we need to move more and more of those calculations into software.
Improvements to or replacements for the spreadsheet as tools for non-programmers would certainly be helpful. But better tools and techniques for programmers to port functionality from spreadsheets to 'real' software would also be helpful.
Earlier quoted context omitted.
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 workb…
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.
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.
One huge reason why Finance pros in general, and Fund Managers, Brokers, Traders in particular, love Microsoft Excel is because all your formulas and calculations update almost instantly (unless you explicitly disable this feature). So they can apply their business and process knowledge to create tables and formulas, pull data from various sources, and create something that is self-contained, stored locally (inside t…
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.
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…
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?