5 ms·

Spreadsheets are widely used in financial institutions, and not just for little things but also for critical tasks too. I've seen spreadsheets sophisticated eno

• powmonk 10y ago
  The insurance industry has a lot of this too. Not as much by the sounds of it but our internal reporting relies on it a great deal.
  • arethuza 10y ago
    A lot of reporting depends on it - a lot of high end financial reporting applications have Excel spreadsheets as their main output mechanism (e.g. Oracle Hyperion FM).
  • ethbro 10y ago
    In my experience, a huge amount of insurance is (various front end systems run by various external sources) -> semi-standardized mainframe intake -> mainframe heavy duty processing -> kick out report of manual work items -> Excel sheet -> manual resolution.
• brongondwana 10y ago
  A spreadsheet can mostly be maintained by the next person to come along. More complex systems often die when the person who knew them leaves. Plus all that stuff about crappy IT departments who don't act as if they exist to serve the actual purpose of the business.
  • arethuza 10y ago
    "A spreadsheet can mostly be maintained by the next person to come along." I do note that you say "mostly" - but I've seen truly epic spreadsheets (including one that my employer at the time spent almost £1 million on) and I'd rather reverse engineer an application with source code rather than a complex spreadsheet (even though the feature in Excel to show dependencies visually is rather cool).
  • cm2187 10y ago
    I have seen enough legacy applications, applications so old no one understand how they work or dares to touch them, or for which we need to pull developers from retirement, software running only on old mainframes, to take the key man risk with business-developed software too seriously. Same thing with reliability. So many of these IT supported applications that are supposed to survive a nuclear strike are down a day a week, while the basic access database pretty much hasn't seen a downtime during business hours since inception.
    • ellius 10y ago
      I think to this point, the organizations that will really succeed in the future are the ones who aggressively hire people with a strong cross of building simple, usable and understandable technical tools who also understand business logic and can communicate. I think soon people will be able get further with some basic R/Python and the ability to write a good email than many of the more technically skilled workers without those abilities.
      • ethbro 10y ago
        To tease out a little more from yours and parent's comments, I think a few things are drastically undervalued by traditional programmers. Tactical initiative: not just for Marines. The closer software is being built to a person who actually posseses the domain knowledge, the less risk of misunderstood requirements / behavior there is. Readability: a language that requires six months to learn to read but expresses programs in half the length is often times not the right choice. If a good enough language can be read by someone with a week of training, and 90% of the domain knowledge is possessed by people who don't know the better knowledge, then use the good-enough language. Reasons like these are why Excel / VBA is used. And moreover, why it (paradoxically to us) works.
• lukezaparaniuk 10y ago
  Not just financial institutions either: I've worked for two global manufacturing businesses – in very different industries – where fundamental parts of their day-to-day operations were dependent on Excel spreadsheets and Access databases. I would absolutely echo all your points, especially the rationale behind "real software": it would have been far more expensive, have taken far longer to be delivered, and that's if it were even signed off in the first place. When management sees "real software" as wholly unnecessary and all you have is Excel, you soon learn to be rather creative.
  • jventura 10y ago
    My experience as well! Once I was contacted by a friend who works on the QA department of a factory (belonging to a multinational company) to implement a system to keep track of the building process (what was soldered, who did it, what tolerances it must have, things like that). The factory's process was entirely modeled in Excel spreadsheets, with the caveat that they took almost 6 months to gather and deliver the data to the client after installing the product on the client site. As it was a freelancing job, I gave them a very high hourly rate, such that it they could forget about it, as it was too much work for one person alone. But in hindsight, I also refused because most certainly it would imply that a lot of the workers in that departament would be made redundant (there were 30 workers there, I would say that at least half would be unnecessary after the system was up and running). If only management understood the huge savings that would be possible.. But in this case, I'm glad they don't!
• Lordarminius 10y ago
  > The business prefers spreadsheets over "real software" because they have complete control of it whereas their internal IT department are slow and expensive, and the resulting custom-coded products are often substandard (see zubairq's comment about paying market rate). I find this very interesting because my company (which I applied to YC 2017 with) is based on exactly this same premise.
• gillianlish 10y ago
  i think businesses actually prefer spreadsheets because they have No control, and therefore no responsibility. if something goes really wrong, they can fire the intern and caim they went rogue. it is much harder to shift blame to a department where everything is full tracked, approved, etc. i think this a symptom of a much bigger hidden secret. corporations are not organized to accomplish tasks. they are organized to avoid responsibility.
• kasey_junk 10y ago
  I've felt for a long time that any application that is targeting businesses as customers would be much better off spending resources on good spreadsheet import/export workflows than on their gui. If you look at your gui and see a grid, basically of any kind, you probably are looking at a point where your customers would prefer to interact with a spreadsheet than your software.
• ellius 10y ago
  The thing I find most amazing about this (I work for a bank) is seeing people make decisions based on version 812 of a workbook passed between 3 different departments with multiple pages where the count of line items doesn't even add up. They're so obviously incorrect and of questionable value, but I've seen managers drop them like they're God's own Truth in meetings. It's that kind of thing that convinces me organizational dysfunction is the root cause of all the mysterious "productivity crisis" that economists often cite.
  • ethbro 10y ago
    Abstraction increases as you move up org charts. Unfortunately, actual process knowledge does not. I blame the "MBAs can do anything" philosophy, but it's probably also a consequence of worker mobility. To state it most simply: if your management (at any level) cannot call bullshit on the data their direct reports provide them (whatever level of abstraction that is), then your business is at existential risk.
    • ellius 10y ago
      Agreed. And then you realize these are the guys that handle the world's money. Not exactly a mystery why the financial industry has a culture problem. I almost had a heart attack thinking about it while watching one of my bosses try to consolidate 13 different versions of a spreadsheet, none of which made sense. And then I realized he's one of the above par ones.
• auxym 10y ago
  I work in mechanical engineering, mostly structural analysis at the moment (ie, figuring out if parts will hold up). Vast majority of calculations are performed in excel. Most engineers know at least a bit of programming from one mandatory class in first year, but for some it's fortran, others it's matlab, vba, etc. Excel spreadsheets are the common denominator. Thankfully, most sheets are rather simple, with one calculation per line, with inputs coming from previous intermediate calculations on the above lines. Unfortunately, sometimes, the logic needs to be more complex, and that's where things go south. Despite all the best intentions, spreadsheets are very hard to test, audit and version-track, and errors will inevitably sneak in. Other things get harder too, when all information is in spreadsheets. Recently I was tasked with updating and reporting about 200 calculations that were contained in 200 almost-identical sheets. A single factor needed to be changed on those 200 sheets, and then I needed to compile the new results in a summary table: relatively simple VBA macro, right? Except multiple of those sheets were just slighlty different, due to multiple engineers modifying them for slightly different cases. The solution ended being similar to scraping really screwed up html with something like BS. A variety of regexes, string searches, and even heuristics based on cell formatting needed to be used. A lot of information was conveyed visually in those sheets (ie, a new calculation block started with a title that was typically bold, blue, and 20pt, but sometimes a bit different). The same thing could've been implemented in python/julia/fortran/heck even C, version tracked and unit tested. Verificating and understanding the calculations is way easier, as all the equations are there in front of you when you open the source file. The program could take input written in simple text file (think ini or even yaml if something more complex is needed), then spit out a report in another text file, or even fancy formatted html. Then, future modifications to handle "special" need not a different program (spreadsheet) for each new case, but in msot cases the master program could be updated while still ensuring backwards compatibility, and all calculations could be rerun in batch from the input txts. Anyways, that's what I dream of sometimes while I'm either doing rote manual excel-scraping or trying to think of a new convoluted heuristic to program it. Unfortunately, the single most important thing for documentation is that colleagues can understand it, and most MEs still see programming as something too complicated and time consuming. I also work in a big corporation, and IT utterly useless. Getting a custom tool made by IT would be a hell of budget approvals, resource plannings and a bunch of three-letter acronyms for at least a year (seriously) before a programmer would strike a single key. Comparatively, a spreadsheet can be bashed out in an afternoon by basically anyone.
• btschaegg 10y ago
  Well, I'd say you can generalize that even further: Spreadsheets are just one symptom. A very inconvenient truth is that wherever you look, you always seem to find far too much critical infrastructures/workflows depending on hacks. Sometimes, something gets publicized. Usually, it will get shrugged off and nothing much will happen about it. This makes one wonder when the whole house of cards will finally collapse...
• dang 10y ago
  I once met with a team of 'business support' people at a large company (not financial—it was in the oil and gas sector) who turned out to be a rogue technical group. Their job was to support the complex spreadsheets made by their bosses. They told me that every 2 years a new batch of software would come out of the IT division, and IT would get a company-wide decree mandating that everyone must use the new software without exception. But the business people had a strategy to defeat this every time. They would simply make sure that "copy/paste" was on the requirements list every 2-year cycle. When the new software came down, they would satisfy the company-wide decree as follows: (1) open the new software; (2) copy the data; (3) paste it into Excel. And then they would continue as before. The only thing that changed every two years was which buggy, slow, and limited in-house application they would be copying data out of and pasting it back into.
  • BjoernKW 10y ago
    Situations like this one are just sad yet unfortunately quite common in the enterprise segment. There's this dilemma that the people buying the software and mandating its use aren't the ones who end up having to use it. So, often ridiculously complex workarounds happen in order to comply with company policy yet still be able to get any work done at all. This quite likely is one of the largest productivity sinks in industrialised societies. There are ways to amend these issues but they require a change both in company policies and in thinking: Allow departments and teams to choose their tools. Have a repository of internally developed tools (Excel spreadsheets, bespoke CRUD applications, shell scripts etc.) for others to share and build upon. Put an emphasis on software quality and user experience.
• gwright 10y ago
  Calca (http://calca.io http://calca.io) is an interesting alternative approach to this problem that uses plain text files (supporting Markdown even) to represent calculations.