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."
My customers are not finance people, but they were using ad-hoc spreadsheets extensively and most of them through G suite. By implementing bidirectional sync for both master data and outputs they have the best of both worlds.
The Google Drive and Sheets APIs (and especially the on-change push notification callbacks) are not a pretty sight but once the twisty maze of nested data structures, webhooks and OAUTH2 and what-have-you were successfully navigated we got an efficient, complete and stable solution that everyone's happy with.
[0] https://support.office.com/en-us/article/Get-external-data-f...
Since it was a system for internal use, that was deemed acceptable.
So that gives the user the ability to query for a certain date, or sum for a date range, or to get a breakdown by some meta data. Being able to load multiple reports allows them to do deltas. And switching to a newer version of the report just takes changing the argument of the load function and press F9.
Worth also giving the users sample spreadsheet, or having a way to export the full report with all these formulas in Excel so that they can learn by example.
The only thing to watch for is memory clean up. You need somehow to have a way to unload all reports otherwise your memory blows up over time.
My Julia code creates Excel sheets including charts and sparks
I use this shiv to Python's XlsxWriter
https://github.com/lawless-m/XlsxWriter.jl
With a bit of effort you can even make it set up scenarios for Excel solver
The only people who think it can be or needs to be done better are primarily not the users.
Excel is the human condition, messy, varied, capable of doing many things and most of the features aren't used, and results are often horrifying. But it works.
That said, I want regex based search in excel, or better data cleaning tools.
At Uni, decades ago (and using Lotus-1-2-3 rather than Excel), we were given a set of spreadsheet templates for a business management exercise (the project ran much the duration of the course). I discovered looking at these that there was an error in the spreadsheet double-counting all inputs (rows and columns were added and the row-totals included in the grand total). Best I can tell, finding that bug was not in fact part of the course goal....
At an early gig doing analytics we hired an old fart who actually introduced some rigour to our project practices, including code walkthroughs. Some of this involved more obviously programmatic tools, but the process was also applied, over the strenuous objections of the analyst involved, to a project largely done in Excel. Numerous errors were found, and corrected. The spreadsheet was also significantly rationalised by having "dumb" data-entry area, and then relying on a sheet with VBA code rather than in-cell logic for the computations.
The analyst continued to object to the code review, after the errors were found and corrected, insisting that it was inappropriate because he "wasn't a programmer". (I looked him up recently, he's continuing to work on analytic projects, two decades on.)
This was also about the time that I first heard of Ray Panko, at the University of Hawaii, who'd found reliably that 88% of spreadsheets had errors. This still holds largely true.
http://panko.shidler.hawaii.edu/
I'm not saying "get rid of all Excel". But I am saying that the tool makes for very, very, very buggy processes, and this is itself a problem.
I'd love to see work toward alternatives that retain the flexibility and versatility of Excel (or other spreadsheets) but reduce the possibility of bugs and errors.
Multiple times I've come across issues like this when developing the replacement for an old access system. The numbers between the new an old system don't match, so you have to dig through both to find the error. If the error is in the new version that's great, but when you tell the boss that the error is in the old one and they've been off by a few million dollars over the years...
However, development costs are so expensive they might have broken even when factoring the cost of creating a system.
Now I just offer handy things like pre-sorting, filtering (some boolean columns to allow them to quickly filter stuff), better column names or reports with extra info. I try to figure out the things they find tedious and automate them once and for all. But I hold back as much as I can.
Couldn't agree more. It's also a huge, latent liability. In my experience, mostly because it's an opaque data store.
To use the parent's example. Turn's out the $100mm business is actually only worth $80mm because someone had accidentally coded GBPUSD directly into the spreadsheet. Before Brexit was announced. Say goodbye to senior trader.
This sort of thing happens though not as much as it used to as we don't allow Excel in the path that hits the ledger.
http://www.codedawn.com/excel-add-ins.php http://blog.malcolmp.com/2010/regular-expressions-excel-add-...
I'm a marketer who echos the "pry it out of my cold dead hands" statement, and this is an interesting aspect of it that I hadn't thought as much about before.
There's really something to be said for having ALL of the data and model at your finger tips for quick sidebar calculations, and there's something to be said for formatting tools to make it easier to read and work with. Often times I'm building a model or report, and need to do some quick checks against different assumptions, or have a little scratch pad of notes or placeholder values somewhere.
Being able to just toss those into somewhere a few cells over so I can see things in context while I work is a godsend. If the model was built as something with a front-end that didn't expose everything, I'd have to manually copy that info out and just do it in a spreadsheet anyway.
I get that there are times when it absolutely makes sense to not have things live in a spreadsheet, and what the risks are around that. But there's also risk in slowing things down, or not having certain things immediately jump out at you because you're seeing all the numbers change, and can quickly modify things as needed to check yourself.
Someone should write a book about productionizing excel models. It's not going away (and shouldn't).
Nah, this is not gonna work... The only way out is to make something that's somewhat like a spreadsheet but with source control, a nicer language etc.
I was writing it and then the firm I was working out threatened to sue me for bullshit IP infringement...
It became an instant hit in that company and I short of a medal :).
Story 1: I Inherited a system once that had 1000s (yes thousands) of excel spreadsheets checked into SourceSafe (yes Source Safe) each sheet represented an Equity Derivatives trade, which was checked out and used by traders when pricing a deal. Also...now it gets fun...there were common functions for calculating the present value and risk metrics for each trade...so when we needed to calculate the risk the traders were running (intraday and end of day) we had a huge compute grid that would check the spreadsheets out and run them on virtualized windows boxes and sum the results to produce the official risk metrics for the bank's trading desk. Absolutely not making that up. I should really write a blog about it...it's truely terrifying.
Story 2: What if I told you that Excel has this little know function called RTD (real time data) that let's you stream data into sheets in well....real time. So you can see all your prices ticking away without refreshing the sheet. I also took over a system that had hundrends of sheets that did this (at this point you must be thinking this guy is a sucker for punishment) one of the problems here was latency...so each trader's sheet used their local machine to get prices...and the analytics library we used to calculate prices to an 'indeterminant' amount of time to execute. Oh...and one of the sheets published the banks prices out to Bloomberg...for trading. This whole mess was sorted out by eventually pricing everything centrally and pushing consistent numbers to bloomberg, the spreadsheets and the risk systems.
My overall summary is that excel is "what is dead but may never die" and you'd better embrace it if you want to deal with front office systems. That and I think people would be surprised to see how much systemic risk some of these places are running (i'm talking about a Top 15 bank here).
I sort of came to love it as a tool, but that's what people with Stockholm syndrome say right?
Pharma company - took the manual Excel process and automated the living daylights out of it so that what the departing analyst took days to do would now be done in minutes.
Petrochemical company - took the reports being done in Excel by a petroleum engineer (each taking 2 hours to do each) and automated to allow him to do the reporting for 50 client companies in under a minute.
Whether Excel or Access, these tools will be used by the SMEs and nothing any IT department does will change this. What IT needs to do, is make sure that the models used are accurate and that the spreadsheets and databases are correct.
Most people who use either Excel or Access make interesting blunders in their creations and end up basing decisions on incorrect output from their creations. It takes an experienced and clue-in developer (IT person) to speak with and then analyse the creations to make sure they actually match what is required.
For those of us who do this kind of work, we must understand that the SMEs are those trying to use Excel and Access and that we are there to help them achieve the SME's desired outcome. The SME's need to understand that they are NOT SME's when it comes to Excel and Access, which most seem to never get this point.
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...
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.
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.
I don't even have excel installed on my windows desktops anymore. A 50 dollar tool from an upstart programmer is better for me than excel.
Let me give you a practical example I ran last week. I want to construct a portfolio of loans starting with an existing portfolio, such that it follow a certain total balance and maturity profile through time, by replenishing it every month with new loans of various maturity (I am solving for the individual notionals of these new loans).
So inputs are
1. the existing portfolio, hundreds of entries with various parameters: start, end, notional, etc
2. the target maturity profile at every point in time
3. the target balance of the portfolio at every point in time
A simple LINQ query won't do. For the example above, you want to model it in C#, but the inputs are lots of tables. In that case I find the optimal way is for the script to accept spreadsheets as input files (wrote a "xlsx (de)serialiser") and output files. Effectively Excel becomes the UI of the script. Nothing beats the Excel UX in giving you the ability to build a table, change or copy/paste data in bulk, etc.
If it were too big (probably not if Excel can handle it) I could also just load up the data into memory via a TSV/CSV deserializer, of which there are a few for .NET. If it comes as excel from the source, excel extraction is a piece of cake these days (the codebase I work on takes excel as raw input for data feeds).
As for nothing else letting you build/change/copy/paste data into a table, Sublime Text Advanced CSV package is fantastic for editing tabular data, and Sublime Text has no problem handling files many gigabytes in size.
Shameless plug: I am a founder of AlphaSheets, a company working on solving all of these issues. It's quite scary (building a spreadsheet is like boiling an ocean) but our mission feels very meaningful, we're well-funded, and we are now stable and serving real users.
A big problem in finance workflows is that there is a tradeoff between several factors: correctness, adoption / ease-of-use, rapid prototyping, and power. We aim to solve several of these major problems. We've built a real-time collaborative, browser-based spreadsheet from the ground up that supports Python, R, and SQL in addition to Excel expressions.
Correctness is substantially addressed, because you don't need to use VLOOKUP or mutative VBA macros anymore. Your data comes in live, and you can reference tables in Python as opposed to individual cells. A lot of operational risk goes away as well, because the AlphaSheets server is a single source of truth.
We help with adoption of Python and adoption of correct systems as well. You can gradually move to Python in AlphaSheets -- many firms are trying to make a "Python push" and haven't succeeded yet because the only option is to move to Jupyter and that's too much of a disruption. It's less brittle than Excel. The important keyboard shortcuts are there.
And finally, the entire Python ecosystem of tools (pandas, numpy, etc.) and all of R is available, meaning that many pieces of functionality that had to be painstakingly built in-house in VBA and pasted around are simply available out of the box in well-maintained, battle-tested packages.
Our long term plan is to broaden our focus into other situations in which organizations are outgrowing their spreadsheets. We think there's a lot of potential with the spreadsheet interface but the Excel monopoly has prevented meaningful innovation from happening. For example, every BI solution tries to be "self-serve" and "intuitive" these days, but encounters resistance from users who end up sticking with spreadsheets due to their infinite flexibility and immediate familiar appeal.
We hope to bring the spreadsheet in line with the realities of the requirements of the modern data world -- big data, tabular data, the necessity of data cleaning, data prep / ETL, the availability of advanced tooling (stats, ML), better charting -- because we think there's a giant market of people waiting to move to a modernized but familiar spreadsheet.
If there's anyone interested, contact me, because I'd be very interested in chatting! I'm michael at alphasheets dot com :)
This is the sexiest thing I've seen since I kissed my girlfriend goodbye this morning.
My father's desk featured one of these, used exactly as described.
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.
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...
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.
The foremost issue was that the timeserver was virtualized, and drifted to an unbelievable degree. This issue was compounded by the fact that we used citrix virtual machines for some applications, and our local desktops for other applications.
The latter issue wasn't a problem until they moved the citrix servers from an on-site server room to cloud provider about 40 miles away. (I think this is when the timeserver became virtualized as well) At that point the latency between the citrix sessions and the local desktops was such that I could create a document on the file share, edit it on my local desktop, close it, save it, and then open it on the remote desktop and it would lock the replication from my computer and lose all my work.
My department managed to wipe out the changes every other department had made to the yearly budget workbook because of this interaction. Of course part of the issue was using Excel as a shared document, but that issue was hugely compounded by the fact that our network infrastructure was bananas.
For instance, building access databases using the Microsoft recommended separate front-end/back-end files, with each individual user having their own front-end file actually managed to make the issue occur more frequently. If you used a single access database file on a shared drive the issue was substantially less likely to occur. I can only imagine this is because the dedupe was postponed until everyone was done using the file, and the file was more likely to substantially change in size when multiple people were using it.
The IT director had an incredibly fragile ego, and he attacked anyone who challenged him in any way. He hired a truck driver (with absolutely no IT experience) to work the IT help desk, which I assume was because he wanted a sycophant. He reported me to HR any time I did anything he didn't understand or which perceived to be a challenge of his power. He reported me to HR for using open-source software, with a description of open source software that made it sound like Wikipedia meets programming, and only used by hackers. He also reported me to HR after he heard I called our IT situation Kafkaesque.
As far as nightmares go, that might have been my favorite, because my defense was literally "it is Kafkaesque, and I can prove it." I managed to successfully convince HR that the IT situation was Kafkaesque using examples from Kafka's work, whose response was "well there isn't anything we can do about it, but you aren't wrong."
The sensible thing would have been to leave as soon as possible, but I really liked the field I was in, which was kind of specialized. Looking back I stayed way too long.
But thanks for the horror story. What a nightmare.
Stories like that, and my experience, tell me that IT staff in large companies and institutions ensure everything works by making it unusable. After all, users won't break stuff if they are not actually using the infrastructure.
When I started, I was backfilling someone who created the Excel model and was responsible for batch exporting data from SAP, crunching the numbers in Excel, and sending that out to the sites every morning. My onboarding consisted of being given his laptop and his login credentials[1], and being met with a desktop full of dozens nested folders of Excel sheets in that exact version control format. I still have nightmares of that week.
[1] My manager had successfully kept IT from being able to get the laptop for re-imaging. But my senior VP located on a different continent had to get involved to get IT to reset the guy's password for us.
unzip *.xlsm
git add .
Also, I wasn't allowed to install version control of any sort, so that's really the bigger problem.
I have no problems about it...less work for me, and they can do their work easily.
It was pretty hacky, but you could pull prices for any security or book in the system, or call any options pricer, as long as the user had the right permissions.
Since the ORM had bindings to stuff like convex quadratic optimizers (IMSL), you could build spreadsheets that let users input linear constraints (e.g. I want to spend less than $50mm and buy between 0-5 units of X and 2-10 units of Y) and then plop the solution vector right back in their workflow. Basically magic to the user, and much better than Excel's 1D root-finder.
Most quants are notoriously bad at building UX, so this was often a much better solution than trying to write a dedicated tool from scratch.
Some things I'd like to see:
- "Git for Excel" Diffs, tags, push changes to individual sheets or regions.
- Snapshots: Create 'Time Machine' type interface for spreadsheet regions.
- Collaborative editing.
- Access control.
- First-class support for model verification (folks roll their own at the moment).
Currently, running SQL and returning the results to a sheet is possible, but very cumbersome now: either .ODC files, VBA, or PowerPivot, none of which are flexible or developer-friendly.
I used ODBC connections to pull in data for further manipulation in Excel to run a ~$200m project for a couple of years. It saved a great deal of time compared to the manual system that was in place prior whilst presenting the data in the familiar excel system which didn't scare away the old baby boomer who was doing all the manual work beforehand. Once I set up the queries and showed him how to refresh the data from the ribbon, he was able to do it without breaking it and whilst still feeling at home enough to get the job done on his own initative.
edit: I note that the above all falls apart somewhat when you need R/W access to your DB. I've only ever done SELECTs because I want to know info from a DB, crunch numbers, then feed decisions into another system. I don't know if you can UPDATE, INSERT, etc. via Excel/MS Query as I've simply never tried it.
A notorious thing that happens in my org is an expert user will extract a bunch of data from the source DB tables and dump the data into an excel spreadsheet. The spreadsheet will pass into the hands of an analyst who will make some tweaks maybe paste in some data maybe manually adjust a few cells here and there and so on and so forth. The spreadsheet will pass into hands of someone else and they will make their own 'adjustments' and so on down the line until finally I will get a phone call along the line of.
"The numbers I have look different to the numbers this other department has in their spreadsheet which is the 'real' value".
Eventually I'll track down the source database and lo-and-behold neither spreadsheet accurately reflects the original database number.
The more hands a spreadsheet passes through the greater the chance of original data being modified into something irreconcilable.
I've played around in the past with linking spreadsheets to DB directly and populating cells via SQL but it fell afoul of requiring various DB/2, oracle, OLEDB etc drivers to be installed on every PC you wanted to open the excel file on and each of those computers required having data source correctly configured via control panel - nightmare for places like my workplace because Windows PC's are all locked down so you'd need to submit a service ticket for every PC you wanted to be able to open spreadsheet on.
This was some years ago but I don't believe anything has changed with way database connection configuration works in Windows client world.
I much prefer the way Dedicated BI tools like COGNOS / SAS etc work. In that situation the user authenticates to the BI software (running on a central server) - the server has all of the DB connections configured and the server executes the DB query on behalf of users.
Our org is currently evaluating a newish Microsoft product called "Power BI" which uses something called an enterprise gateway more info here https://docs.microsoft.com/en-us/power-bi/service-gateway-on... I don't know all the details but seems promising solution for our org's data sharing issues at least.
I really thought PowerPivot could be this excellent data tool, but the DAX formula language is just such a pain. I really dislike it. Using SQL og C# is just much more intuitive - especially SQL.
But basically, I kind of just want a simple API for interacting with workbooks and providing functions, maybe using embedded JS or Python scripting. That, to me, sounds like it would make Excel a lot more palatable toward developers like it is toward end users. (Honestly, I think what I'm describing is a bit like WebExtensions but for Excel workbooks. I'd dig it.)
Spend a few million on a web based reporting system. Allows self service reports using real time data. As it runs on a browser literally anyone can use it.
Only problem - formatting and printing is for shit and users want it in excel so they can manipulate and format data how they want, on the pages they want, in the colors and font sizes they want.
I agree with Excel not being the most stable or error free platform for reporting, but is there any easy to use alternative? Whatever we try we keep coming back to Excel/spreadsheets.
I believe OnservableHQ has a good shot at it.
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 needed.
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.
Straddling the line between 'technically best outcome' and 'cheapest workable outcome' is what businesses strive to do. In most mature businesses change should be approached extremely cautiously; everybody loves changing things and the costs are frequently big.
The big grid of cells is the weakest part of Excel by far!
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.
Then we move on to math, and we still do it with paper, almost as an extension of writing. When doing calculations in class it is natural to keep calculations and values in some type of invisible grid pattern that makes sense to the student. Then we get to the computer, and that format still follows.
Except that the first information processing a person does isn't reading at all. It's learning sounds and words, and we do that by listening and watching others do it. And the first thing we create isn't words on a page, it's likely something physical, in the form of building blocks or some other toy. This type of learning is great, but it can't be replicated well in a school system because it is expensive and doesn't scale well to the real world. If you're going to engineer and design a bridge, you're not going to start by making a bridge. So we're taught to make lines on paper that represent a bridge.
This is where (I hope) AR/VR becomes disruptive. An infinite amount of objects that can represent any piece of data on any scale in non space.
Think about how successful minecraft is. When I first played it made me realize how much creativity I had lost to pen and paper through no fault of my own. I was building logic gates without even realizing what formal logic was until I came to college.
Now make it engulf me, make it blank, and give me a wand and an in game terminal.
Since this thread probably has more Finance users than usual - most people have seen a bloomberg terminal. Its ugly, and filled with arcane short cuts.
Its extremely extremely good at getting its job done, and keyboard short cuts and commands are the fastest system once you gain expertise.
Keyboard short cuts and memorized lists of invocations will regularly be the fastest way of activating commands on a system for experts. Especially once it becomes muscle memmory.
For most abstract symbol manipulation, most jobs can get away with a stack of 2D pages.
If you are working in 3D, then you are doing a pretty unique set of modifications, and the average case will not apply to you.
Which is to say that AR VR will be only for a very niche set of uses.
Operators are so in tuned with the incoming data that they intuitively make 3D maps in their head, while requiring 2D data for quick observation, comprehension, and real-time monitoring.
Working in a 3D space makes sense for blocking out movies, exploring physical architectures, or certain kinds of research. For everything else there universe has given us an amazing parallel processor connected to eyes that work really nicely on tabular data.
If something comes out that can help students who struggle with math visualize those concepts in a more (to them) natural way I will be thrilled. To me these concepts were always very visual, and allowed me to pick up concepts in class by thinking that way. I only have experience in the U.S. education system, and in my experience it felt that my teachers always taught in a way that emphasized problem memorization and notation over actually understanding, mentally, the abstract concepts and problem solving. This seems like a barrier for the average student, and leaves a lot of people feeling left behind or "not smart" even though it is likely a fault in the way they are taught.
If something comes out that will allow those mental barriers to be broken, I will consider it a win.
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 of a spreadsheet, we'll make you a nice system for it, cause your stuff will blow up."
- several months later the IT guy comes back with a web app that does the same thing as the spreadsheet.
- old trader guy says: "hey I can't copy shit around, my shortcuts aren't working, I need to be able to do basic maths on the side, I can't save my work, etc."
- IT guy: "ok I'll make you an export-to-Excel button"
Seriously I've seen this happen over and over again.
The issue is not how to get rid of Excel, it's how do we make a better spreadsheet...