It amazes me to see companies big and small that basically run on Excel.
Why do you think Excel is so ingrained into all kinds of companies and processes?
Why do you think Excel is so ingrained into all kinds of companies and processes?
> Why do you think Excel is so ingrained into all kinds of ...
Programmers underestimate and put down excel all the time, but I think it's actually how many projects they end up with get started.
Someone had a problem, solved it for themselves using excel, got noticed, expanded the solution to other problems until the excel solution itself became the problem and then... it ends up as a project for you.
There's nothing wrong with that. It does the job, and it's not like the first course of action when there's a problem should be to assemble a scrum team with a cast of characters like a sitcom, and blow a million dollars to implement a bespoke software solution. Sometimes excel is just enough (and then some).
Also in the same project I remember another Excel file with mechanical calculations that actually updated a nice graphic that simulated all the linkages and different extensions of the actuators and computed forces at different points. The unholy alliance of elegant Lagrangian mechanics with Visual Basic.
I hope to never touch Basic again but it was a valuable lesson about getting things done and I'm glad I took it so early in my career.
Because you should have a reeeealy good justification to write a single line of code for something that can be done in Excel much cheaper, and mostly you don't.
Take a look a talk by Joel Spolsky called You Suck at Excel. It's on YouTube. It will give you a quick glimpse into how Excel powerusers are using it and how fast you can create something useful.
- Because Excel allows the user to (i) perform ad-hoc calculations, (ii) audit the input and outputs, and (iii) easily modify the functionality in real time.
- People don't like filling out forms and most web apps are basically filling out forms.
Say we had a REPL that also had a table (like excel, each cell has an address... a 2D stack if you will).
Say we interact using a mouse to select a cell or in the REPL to specify what cell we want to write to. Then, if we use a Lisp, we have tabular code and tabular data...
I might code this up for fun.
Or a spark interactive cluster with a notebook interface if you have more data than can fit on a single machine
Also, the #1 Excel rule in Wall Street is "never use your mouse"
IMHO, I think the better project is an equivalent of an RMarkdown / RStudio tool that generates a final report from a declarative set of instructions.
From the "Introduction" [3] of its Online Documentation: "Siag is an X-based spreadsheet for Unix. It uses Scheme (a Lisp dialect) both for expressions and as an extension language, which makes it easy to create new functions (for native Lispers, that is). There is no requirement to know Scheme to use Siag, expressions can be entered in traditional spreadsheet syntax as well."
About point 3, isn't a spreadsheet basically a sophisticated form?
I've seen it countless times. Somebody sends an excel file over e-mail and it is either an old outdated version of the file, or the persons that receives it hangs on to it for months as a source of reference.
MS Access is much better for allowing simultaneous editing, especially (IIRC) if it's backed by an RDBMS, since it will use row level locks.
My previous employer had several databases with read-only web interfaces, but Access editing interfaces. They're very fast to develop, and support all the usual database features (constraints, keys, search etc), and could be set to load a form-editing view by default.
But even if you are just using it as a form, with bulk operations and keyboard shortcuts, it's usually much easier to fill out an Excel form vs. a web / app form.
People/teams/companies need different degrees of security, complexity, data, etc to their day-to-day operations. Someone may be interested in fiddling with data without others seeing, others may not want to share certain data broadly (answering your point below). Excel has served as a way to unify these needs for the most part. Some other options available tends to fall on the outer-layers, where excel may not be optimal and someone felt a specialized tool could improve speed/quality/cost.
Not everyone can code, but everyone can transform data in a spreadsheet and email it off to the next person.
I've seen people having multiple versions of the same excel file and not remembering which was the last one...
...and here: https://easasoftware.com/case-studies/leaseplan-transforming...
I would theoretically be possible to write some software/reporting solution for every use of Excel but it wouldn't be an efficient use of resources.
And as you're adding features, you instantly see the results; even as you type if you use the formula builder.
If you're working on any kind of software tooling, watching how people work with Excel is incredibly insightful.
Spreadsheets are nontechnical users' version of "move fast and break things". Often times that can be useful, even essential, but there are many more cases where the primary utility of working that way is also the major flaw. Its faster than traditional report development because it skips any kind of review or QA.
One company I know which did this was called "Actuate"; that was years ago, a quick googling shows they were bought, now called "OpenText" (?) - also had something to do with MongoDB and something called BIRT (Business Intelligence and Reporting Tools)...
Last I had any involvement with them for a company I worked for, it was with their reporting suite of tools; the company I worked for became a VAR for them, so anytime the tool had a bug, we could quickly get them in an IRC chat (told you it was a while back) and get a patch within a few hours to a day or so, depending on the issue.
The reporting system was fairly unique for the time; a basic WYSIWYG drag and drop editor, ala VB - and for more complex designs, a VB-like object-oriented "reporting design" language. It was essentially what VB6 should have been on the OOP side of things, but geared entirely toward reporting.
Reports could pull data from any number of different sources, from flat ascii files, to excel documents, to database engines, ODBC, etc.
One of the last things I heard from them, at a seminar they put on that my company sent me to in Santa Monica, was this idea of reforming people using Excel spreadsheets. They called the whole sharing and copying of such spreadsheets, such that there was no one single authoritative source - a "spreadmart". So they wanted to do something about it.
They came up with some kind of Java-based solution with a custom front-end that looked exactly like Excel of the time, worked just like it - pivot tables, whole nine yards. But it interfaced to a backend using these "business logic" modules. The idea was all instances of the "spreadsheet" could see the same data via those modules, and those modules would be created by an IT staff (or DBA or something), and anything interacting with them in a company would have to go thru them - reports, gui, excel spreadsheets, etc. The idea was to present one cohesive view of the data for all users.
I don't know where it ended up - if they launched the product or not (we were being given a sneak peek at it at the seminar - it was a pretty nice demo, overall for the time).
A couple of weeks after coming back from the seminar, the company let me go (I'd worked for them for about 8 years - missed the whole "dot-com" thing because I believed in this company so much - lived and learned).
* No need to depend on an IT department which is already overbooked
* No need to find budget to fund a project
* No need to wait forever for the IT project to finish.
It gives an business person control, as they can do it themselves.
Their manager wants them to use Excel because all their past managers have wanted them to use Excel. And so on.
Also, it's already there on all the computers.