Live data from Hacker News

Stop Using Excel, Finance Chiefs Tell Staffs

wsj.com

321–330 of 435 posts

Re: Stop Using Excel, Finance Chiefs Tell Staffs

#321

Earlier quoted context omitted.

The issue isn't that you can't program in excel the issue is that excel lacks many of the safeguards that have been built around programming in the last few years. Version control for excel is terrible at best. Code review is basically non-existent and how could it be when logic is split over several cells and variables are named $A17 or B23. I think the win with excel is its super simple interface, that said there i…

> variables are named $A17 or B23. Excel lets you name tables, cell ranges, or individual cells. I have seen spreadsheets put together by people who take the time to do this, and they are remarkably readable!

Way back before they added visual basic into it Excel had what was called a Macro language that was also built in sheets - just slightly different appearance (very wide cells) and altered functionality (to prevent you from doing numerical operations to your macro code). I think this was around version 4?

Anyway, it basically worked like a stack, with the currently selected cell being the instruction pointer. So when debugging you could either look at your data and watch blocks of numbers flashing in and out of existence or changing state, or look at the macro sheet and watch the pointer bounce around as it went to different branches or sat in loops or whatever. There were commands to turn screen updates on and off (which sped things up considerably) so as you got more and more of it working it would go from looking like some confusing nightmare to a smooth list of progress bars and passed sanity checks.

They moved to VBS because programmers were finding the cell model too restrictive/weird, and for integration with Access, but doing it all in cells was remarkably and pleasantly like assembly-level debugging. You'd hack something up quickly, figure out your algorithm, then name the ranges and use and index value, and you could lock ranges and what-all else. It wasn't as easy to read as a page of code (eg no whitespace) but the crudity of it pushed you towards that sort of 1-operation-per-line discipline that assembler demands and really forced you to think about semantic efficiency. I had macros consisting of thousands of cells of code with every single operation commented. You could, in turn, name the ranges that had macro code in them and do code profiling to find out where your performance bottlenecks were, and so on.

Re: Stop Using Excel, Finance Chiefs Tell Staffs

#322
post #18

I would argue that the most commonly used programming language is Excel. But few of the people using it realize they're programming. It's a brilliant reactive data programming model that makes intuitive sense to non-technical users. They feel empowered to use it to solve problems right now with a computer. They experiment with it, try things, Google how to do more things- just like any programmer does. And they feel…

I used to be a Lotus Notes specialist, and one interesting thing I noticed is that from the earliest versions it was designed specifically to be a "step up" from a spreadsheet (Lotus of course also made Lotus 1-2-3, which was the original killer-app spreadsheet before Excel took over). Notes still let you see data as rows and columns and had very spreadsheet-like functions, many of which could be transferred directly…

As a Lotus specialist I can see why you'd think Lotus 1-2-3 was the original killer app spreadsheet and as someone who worked retail at the time selling UNIX and Microsoft machines I'd have to say we sold a ton of Lotus 1-2-3.

But we have to give Dan Bricklin and Bob Frankston their dues because Visicalc is the original killer app spreadsheet in the literal sense: people used to say they didn't know if Visicalc sold more Apples or if Apple sold more Visicalc. It truly was the program for which people bought the platform.

Re: Stop Using Excel, Finance Chiefs Tell Staffs

#323

Earlier quoted context omitted.

There are upsides to excel in cases like that… The health insurance people of various sorts who use this setup are the ones with domain knowledge. With an excel program, they can (1) understand how it works (2) add to it, modify it (3) create a copy and break it (4) debug it (5) have ideas about how it could work differently… I’m not saying that excel is the tool for the job (sounds like it is definitely not), and th…

"If the excel team was blessed with a plague of inspiration tomorrow morning, Is there a way they could make it so that excel is the right way to manage an insurance business?" What a professional software developer's workflow has and Excel lacks: * principled way of sharing code across a team with distributed source control (or similarly powerful tool), * automated regression tests, * input validation, * continuous…

You underestimate how difficult it is to work with at least some software companies, how expensive it is, how difficult negotiation it takes to convince quite a few nerds that user actually has business case for that requirement. And many software companies produce poor quality and are very slower then necessary despite using all buzzwords and all nighters. Managing even outsourced projects takes learning and expensive failures are nor an exception. All in all, the software we all collectively produce is still very expensive and unreliable.

Even absent that, it is difficult to explain what users need to coders who have zero idea about the domain. Unless it turns out they are the kind that just know user is idiot the moment she has different opinion on her own job, in which case expect needed time to tripple.

The homegrown excel is awesome analysis once the company decides to move on. It is concrete, you can generate test cases from it, it has features.

Re: Stop Using Excel, Finance Chiefs Tell Staffs

#324
In my enterprise, PowerBI, Flow, and Powerapps are the microsoft products helping to move data out of excel, or at least helping to make it visual and shareable.

If any of those products grows a more user friendly model for _thinking_ about how to do things (Flow is arguably the closest) they could revolutionise how things are done here. PowerBI has enormous power to express data as stories, but the technical hurdles are still high. It's not _harder_ than excel, but there's a competency cliff.

Re: Stop Using Excel, Finance Chiefs Tell Staffs

#325

Earlier quoted context omitted.

I used to be a Lotus Notes specialist, and one interesting thing I noticed is that from the earliest versions it was designed specifically to be a "step up" from a spreadsheet (Lotus of course also made Lotus 1-2-3, which was the original killer-app spreadsheet before Excel took over). Notes still let you see data as rows and columns and had very spreadsheet-like functions, many of which could be transferred directly…

> my career in business software has still mostly been about converting spreadsheets into more "proper" applications. Still true for many people in 2017. @patio11 probably said it best: > Every spreadsheet shared in a business is an angel announcing another SaaS app still needs to be built. https://twitter.com/patio11/status/655674551615942657 FWIW we ended up in business software after one of our open source librari…

True but there is a threshold. If the problem is small enough, you can't beat an Excel spreadsheet's flexibility and low startup cost.

Having worked with a number of finance teams, the biggest problem is not when Excel is used as an analytics tool but as a financial database. Excel as a source of truth for financial data is truly terrifying. Even financial audits are still often handled with custom data pulls exchanged over Excel spreadsheets.

Shameless plug: that's why we ended up developing one of those SaaS tools (http://modfin.io). It lets finance teams map their source data to a proper, easily auditable accounting ledger so that they don't need to do their "magic" in Excel.

Re: Stop Using Excel, Finance Chiefs Tell Staffs

#326
Shudder

This reminds me of my 2 months working for a Big 4 accounting firm in, basically, SOX auditing.

We mapped out controls on our little 14" laptop screens using excel spreadsheets with tens of thousands of rows and hundreds if not thousands of columns.

I'd say we were writing novels in Excel but, to be honest, there were probably far more words than the average novel contained.

Talk about using the wrong tool for the job -- and using low-paid monkeys on inadequate equipment rather than developing a proper application for the task (or paying someone else to do the same).

I'll never look at excel the same way again.

Re: Stop Using Excel, Finance Chiefs Tell Staffs

#327
post #18

I would argue that the most commonly used programming language is Excel. But few of the people using it realize they're programming. It's a brilliant reactive data programming model that makes intuitive sense to non-technical users. They feel empowered to use it to solve problems right now with a computer. They experiment with it, try things, Google how to do more things- just like any programmer does. And they feel…

I found this just the other day: A User-Centred Approach to Functions in Excel [PDF][2003]: https://www.microsoft.com/en-us/research/wp-content/uploads/...

Re: Stop Using Excel, Finance Chiefs Tell Staffs

#329

Earlier quoted context omitted.

> my career in business software has still mostly been about converting spreadsheets into more "proper" applications. Still true for many people in 2017. @patio11 probably said it best: > Every spreadsheet shared in a business is an angel announcing another SaaS app still needs to be built. https://twitter.com/patio11/status/655674551615942657 FWIW we ended up in business software after one of our open source librari…

No. An domain-specific SaaS app takes all the power away from the people writing their spreadsheet programs. Only one app is needed, a hosted spreadsheet with backup and versioning an replication. The only domain-specific business is in writing plugins.

I wrote this in another thread, but I think the next move should be to create an Excel-compatible spreadsheet program with a few additional constraints inspired by programming. Make primary keys required, each column needs a type, etc. These are concepts I’ve successfully explained to non-technical coworkers to great effect. By enforcing them in a tool, I think you would get about 80% of the benefits of true software without all of the overhead that entails.

Re: Stop Using Excel, Finance Chiefs Tell Staffs

#330
post #146

Earlier quoted context omitted.

> There isn't an IT department in the world that can develop centralized IT solutions fast enough to keep up with the ways employees slice & dice data. That's why Excel is "overused". It wasn't very long ago that I realized that my two decades in IT could be summed up as: making proper applications out of Excel workbooks with feeble macros. I hate Microsoft as much as the next Linux zealot, but dang if they didn't cr…

>making proper applications out of Excel workbooks Yes, exactly. If we're being uncharitable, we can spin Greenspun's 10th rule[1] of programming as: >"Any sufficiently complicated Excel spreadsheet contains an ad-hoc, informally-specified, bug-ridden, slow implementation of a proper centralized database." Or, if we're being charitable, we frame it as an internal MVP (Minimum Viable Product): >"Spreadsheets are the i…

I’ve just done exactly this: replace an old xls file which was sent each month by email with a simple web based application. The app includes some nice dataviz.

But then the people keep asking “how can I export to excel”. One user was copying an html table split in 20 pages one by one to excel.

So I found a elegant and simple solution: an excel spreadsheet linked to the PostgreSQL db of the app via ODBC. Now users can just click on Refresh All in excel and get the latest data. I’ve also added an “click here to open” link in excel which opens the form with the row’s id in the web app.

Now everyone is happy: the data is kept centralized and available to everyone in real time. And users can make all the pivot tables and pivot charts that they want natively in excel.

Do not underestimate the power of ODBC with excel!

(may not work for big data though, but most business app do not contain more than a few thousand rows)

Post reply on HN