I also saw lots of people using Excel for automation of things. I wonder if the problem that we have with Excel is that we are so used to a program using a 1D representation. If we manage to switch to 2D, we might enjoy the good things that spreadsheets have to offer.
Quite possibly, though I never really saw any true use of the 2D space, it was either just 1D structures lined up next to each other so that you could see them simultaneously, or a frustrating 2D mimicry of an actual database with sorted fields and the like. I'd really like to try Pandas or similar, that might also help a switch to 2D :)
On a recent Ruby Rogues podcast one of the guys mentions that if you want to see what software applications need to be build in an organization, see what people are doing with Excel.
"Excel is a coping method." - James Edward Gray II
This has definitely been the case in all the companies I have been at.
In my opinion, business and management need programmers, it’s just that no one has told them yet.
This is very true as it is true the reverse.
The reason why this is very true is that big corp are using incredible amounts of man hours dealing with spreadsheets madness. There is no knowledge of the basics of programming or even simple SQL. This means that things as simple as a "group by" become a total nightmare: try to "group" data from 100 entities around the world sent in 100 Excel email attachments. Try dealing with people that put the "Intraco selling expense" in the wrong cell or things of that type. Again, with 100 entities/files. This is a big part of the reason people end up overworked... especially in such fields as finance.
The reason why it is true also the reverse is that for how much BS programmers may see in the business/finance world, there is a part of sense to that madness. But it takes time and patience to see it. Mostly I don't see "real" programmers/geeks having that kind of patience. So, if any enterprise product wants to solve the data nightmare in which all Big Corp live, a reach to the business people would be a good first start. But that is tricky and difficult from both sides.
Well, long post, but a nice issue that needs some good solutions. If anybody is interested, I work in finance (...) and I do love programming, I am quite interested to discuss this topics.
This brings to mind ResolverOne - a spreadsheet that "compiles" down to python. Basically they had a similar insight - that people who do heavy excel are essentially programming. So they made it easy for devs to convert the spreadsheet to programs by allowing them to be converted directly to code/workflows.
I met those guys at PyCon a few years back, and they provided some cool insights that jive with this article:
* A spreadsheet is essentially a functional program
* Why ask biz/financial analysts to work in a paradigm other than spreadsheet - its been honed to their task over decades now, instead programmers should better work with it.
* There are very cool human-in-the-loop workflows that can come out of this symbiosis, let the computers do what they are good at, and the people do their part, rather than force one into the role of the other.
Note: I'm not involved in Resolver systems in any way, I just think they have a neat product. Serious questions are probably better directed to them, but I think they are HNers too, so maybe they can chime in.
At Goldman Sachs they have a programming environment called SecDB that most business is done in. The language, Slang, is a dynamically typed scripting language similar to Python/Ruby.
One of the many reasons Goldman's strategies group has been so successful for the past 15 years or so is because they don't hit a productivity brick wall of emailing broken excel sheets to each other the way many other financial orgs do.
I think this is an area that is screaming for innovation.
Top problems with excel:
* Much of building a spreadsheet model is copy and paste programming, either literally, or aided and abetted by the ability to "fill"
* you can't easily diff different versions of a workbook to see how the code has changed.
I'm sure there is more, but I haven't had to really do much in Excel lately, so I've blocked out a lot.
7 comments
[ 2.4 ms ] story [ 31.2 ms ] thread"Excel is a coping method." - James Edward Gray II
This has definitely been the case in all the companies I have been at.
This is very true as it is true the reverse.
The reason why this is very true is that big corp are using incredible amounts of man hours dealing with spreadsheets madness. There is no knowledge of the basics of programming or even simple SQL. This means that things as simple as a "group by" become a total nightmare: try to "group" data from 100 entities around the world sent in 100 Excel email attachments. Try dealing with people that put the "Intraco selling expense" in the wrong cell or things of that type. Again, with 100 entities/files. This is a big part of the reason people end up overworked... especially in such fields as finance.
The reason why it is true also the reverse is that for how much BS programmers may see in the business/finance world, there is a part of sense to that madness. But it takes time and patience to see it. Mostly I don't see "real" programmers/geeks having that kind of patience. So, if any enterprise product wants to solve the data nightmare in which all Big Corp live, a reach to the business people would be a good first start. But that is tricky and difficult from both sides.
Well, long post, but a nice issue that needs some good solutions. If anybody is interested, I work in finance (...) and I do love programming, I am quite interested to discuss this topics.
I met those guys at PyCon a few years back, and they provided some cool insights that jive with this article:
* A spreadsheet is essentially a functional program
* Why ask biz/financial analysts to work in a paradigm other than spreadsheet - its been honed to their task over decades now, instead programmers should better work with it.
* There are very cool human-in-the-loop workflows that can come out of this symbiosis, let the computers do what they are good at, and the people do their part, rather than force one into the role of the other.
Note: I'm not involved in Resolver systems in any way, I just think they have a neat product. Serious questions are probably better directed to them, but I think they are HNers too, so maybe they can chime in.
One of the many reasons Goldman's strategies group has been so successful for the past 15 years or so is because they don't hit a productivity brick wall of emailing broken excel sheets to each other the way many other financial orgs do.
Top problems with excel:
* Much of building a spreadsheet model is copy and paste programming, either literally, or aided and abetted by the ability to "fill" * you can't easily diff different versions of a workbook to see how the code has changed.
I'm sure there is more, but I haven't had to really do much in Excel lately, so I've blocked out a lot.