5 ms·

Excel is one of the most successful pieces of software of all time, so it's an odd choice for a punching bag. Plus, the tone of this article is (unintentionall

Excel is one of the most successful pieces of software of all time, so it's an odd choice for a punching bag. Plus, the tone of this article is (unintentionally, I'm sure) off-putting, particularly: > You know what happens with Excel. Karen from accounting builds a “simple” spreadsheet to track expenses. Six months later, it’s a 47-sheet monster with circular references and VLOOKUP formulas that would make a mathematician weep. The company depends on it, nobody understands it... It sounds like Karen did a valuable service to the company. She combined a technical skill set with her domain knowledge to create a system that was so successful that the company now depends on it. Cleaning up the technical debt seems like a task that's well worth the cost. > ...And when it breaks (not if, when), guess who gets called to fix it? I'm not sure, honestly. It depends on whether you want the fix being done by a resource you consider to be a cost center or a value center. The former will do the cleanup job for bottom dollar. The latter would team up with Karen to amplify the project's impact while cleaning it up. For these reasons I think your analogy is not effective. I don't disagree with your thesis, though; I prefer code in almost all cases. But that's just me. I know for certain, though, that if I had stock options in that company in this hypothetical scenario I'd rather keep Karen around than whoever fixes the VLOOKUP syntax. And if visual tools are what empowers Karen... well, there you go.

0cf8612b2e1e 1y ago
I too never get the Excel hate. Without Excel-what do you expect non programmers to do? They sit in front of a computer all day long-would you prefer they use paper? Official IT resources are a joke and will never deliver something so understandable and malleable as Excel. Sure, the official IT app may be done the right way, but it will quickly become outdated as business processes change and the maintenance budget disappears.
- bryanrasmussen 1y ago
  I mean I hate Excel - for me. Not for anyone else. I think it is a great piece of software and I only wish I could make something as successful. But I definitely hate working with it.
antisthenes 1y ago
> It sounds like Karen did a valuable service to the company. She combined a technical skill set with her domain knowledge to create a system that was so successful that the company now depends on it. Cleaning up the technical debt seems like a task that's well worth the cost. The technical debt here was solved by creating a complex Excel worksheet. The sheet is the solution. For small companies where these Excel monsters get created, it is the #1 best way (read - cheapest) to solve technical debt, which, before Excel, was probably a bunch of arcane manual processes that took 5x as long with worse accuracy.
- jdauriemma 1y ago
  Good point, though not all spreadsheets are created equal. Some get quite unmanageable, and that can be a productivity bottleneck over time (unless you're not really adding new use cases)
  - Ezhik 1y ago
    Maybe the real problem to solve is not killing Excel but providing a pathway for load-bearing Excel sheets to grow into full applications, development practices and all.
    - jdauriemma 1y ago
      I feel like this is doable with a good LLM-assisted coding tool, but it's just a hunch.
    - antisthenes 1y ago
      I think the hardest part here is UI. With Excel you get no-code immediate UI feedback in the cells. Most people will use an Excel sheet as an array or a dataframe.
- dalibenothmen 1y ago
  Thank you for your comment.Totally get what you’re saying and yeah, that’s a solid take. My main point was more about what happens next when those "Excel-as-solution" systems grow beyond their original scope and start needing maintenance, collaboration, or scale. That’s where things can get tricky. But I completely agree Excel often is the hero in the early stages.
betaby 1y ago
> Excel is one of the most successful pieces of software of all time This is constantly repeated truisms, and yet I don't use it and have no plans using it. I'm certain I'm not alone. Excel is counterintuitive and not 'consumable' as the opposite to SQLite. Surely I understand it not the same. Also I suspect most of the Excel users use it like CVS editor.
- TZubiri 1y ago
  Tell me what other piece of software gives so much turing-complete power to non-technical users. "Karen" can literally write programs with little training, there's memory, there's functions, there's references, excel is the best.
  - betaby 1y ago
    Problem arises when "Karen" leaves the company. Then the company asks the "IT guy" to "help" with that Excel sheet on a shared. Again, as I highlighted Excel sheets is not a 'consumable' software. OK to use for one time things, but in a long run it's most likely a mistake.
    - afiori 1y ago
      Famously Jane's Street started by using excel automation for its core trading business. I do not particularly like excel, I find it interesting but often obtuse and limited in annoying ways and I agree that for an established workflow using "proper" code is generally better. But imho where Excel excels is in dynamic exploration and supporting decision making, where the type of analysis and visualisations you might want to do can change radically and quickly
    - nyeah 1y ago
      We never ever see this scenario happen with code :-)
- narcraft 1y ago
  Anyone who hasn't used Excel is totally out of touch with reality (constrained to developed world). Excel is counterintuitive to whom? What intuition does it upset? It's a grid of cells. Each cell can reference any other. You can immediately see the definition of any cell when selecting it. I'd wager that it's used as a presentation or modeling tool far more than as a CSV editor. Its dynamic aggregated views, what-if scenarios, charting and dashboarding hardly could be replicated with SQLite or CSV tools alone. Surely not as seamlessly or intuitively as Excel.
fellowniusmonk 1y ago
The real problem is that even though most problems are actually text problems (or can be represented by text chars) we don't have version control with the same level of granularity for spreadsheets.
- inetknght 1y ago
  Really? What's a database? A spreadsheet. Databases can have version control, backups, etc. And, what's git? A spreadsheet can be committed to git. Version control for spreadsheets? It'd be awesome to have on its own, but it's also not hard to add it on top of spreadsheets' existing features.
  - afiori 1y ago
    It is often said that xlsx and docx files are basically zipped folders of XML files and assets, I wonder how effective it would be to add the decompressed forms to git to see and track changes (or similarly for git to show diffs for the files inside a tar/zip
    - thankyoufriend 1y ago
      Not hard at all as it turns out. I had to do this a few years back to extract PBI metadata (metric names, queries, data sources, etc.) from of our dashboards.
  - fellowniusmonk 1y ago
    I hope you realize you aren't disagreeing with me. That's exactly my point. It's always interesting to see where developers don't build obvious solutions into existing tool. You're very right that it's not hard, but to me, the fact it hasn't been done, is interesting thing from a sociological perspective. I've seen many code editors with amazing git ergonomics built in, never for spreadsheets. I'm actually working on text only spreadsheet markup that is human intuitive and building interfaces to go with it.
TZubiri 1y ago
"I'm not sure, honestly. It depends on whether you want the fix being done by a resource you consider to be a cost center or a value center. The former will do the cleanup job for bottom dollar. The latter would team up with Karen to amplify the project's impact while cleaning it up." This is not the first time I see developers berating non-technical users, and I like the thesis that they will function as cost-centers that will do a cleanup job instead of teaming up with the user. It's like they will attempt to "do the work" in a binary fashion, making the "correct" choices, often focused on technical factors, like which library to use or what algorithm, instead of focusing on the business domain. I also see this attitude when facing technical issues or bad code as if it wasn't our job to deal with bad code (and as if non-bad code existed)
brendoelfrendo 1y ago
>> ...And when it breaks (not if, when), guess who gets called to fix it? >I'm not sure, honestly. It depends on whether you want the fix being done by a resource you consider to be a cost center or a value center. The former will do the cleanup job for bottom dollar. The latter would team up with Karen to amplify the project's impact while cleaning it up. You're right that the answer is "it depends." In the world of risk management and audit, what Karen has created is called a "user-developed application." Her employer should give her a big pat on the back, and then take a step back to decide 1) if this Excel spreadsheet is mission critical, 2) if it is, who will maintain it, and 3) whether its importance justifies building a formal IT solution to support the business function (either in-house or using COTS software). I agree that Karen did nothing wrong! She found a process that could be improved or automated, and was able to use technology to do it. If someone is caught off guard when the Excel file goes kaput, then that's not Karen's problem nor is it her fault; it's her employer's responsibility to pay attention to their own business requirements.
iLemming 1y ago
> Excel is one of the most successful pieces of software of all time, so it's an odd choice for a punching bag. So is Photoshop and Google Maps - the point of the article isn't bashing on Excel, it's about choosing the wrong tool for a job.
dalibenothmen 1y ago
Thank you so much for this thoughtful comment. I want to start by sincerely apologizing if the analogy came off as dismissive or disrespectful. I didn't mean to diminish from excel at all, in fact, you've highlighted exactly why Excel is so powerful and why my analogy works, just not in the way I originally framed it. Let me clarify what I was trying to get at: Excel's success comes from empowering domain experts like Karen to solve real problems without needing a computer science degree. That's genuinely amazing and valuable. The "problem" isn't Excel itself or Karen's contribution, it's when the tool becomes the permanent solution rather than a stepping stone. My point about visual workflow tools was similar: they're incredibly powerful for rapid prototyping and getting things done quickly. But when professional developers (whose core skill is writing maintainable, scalable code) use them as their primary solution, we might be missing opportunities for more robust, long-term approaches. You're spot on about the value vs. cost center perspective. In Karen's case, the smart move is absolutely to work WITH her domain expertise while adding technical structure. Similarly, visual workflow tools can be fantastic for proof-of-concept or when you need something working yesterday. I think my tone came across as dismissive when I meant to be more reflective about when we choose the right tool for the job. Thanks for pushing back on this, it's made me think more carefully about how I frame these discussions. Both Excel and visual workflow tools have earned their success for good reasons.
- jdauriemma 1y ago
  I think I might have phrased my criticism too sharply, sorry about that. I wouldn’t have commented if I didn’t think you were making a worthy point though! There was an article about malleable software recently that used avocado slicers vs. kitchen knives as an analogy; the more I think about your piece, the more it resembles that concept. https://www.inkandswitch.com/essay/malleable-software/ https://www.inkandswitch.com/essay/malleable-software/
  - dalibenothmen 1y ago
    No need to apologize at all. I really appreciate you taking the time to engage thoughtfully! Your feedback helped me clarify my own thinking, which is exactly the kind of conversation I love. And that avocado slicer vs. kitchen knife analogy is perfect, it captures the nuance so well. Some tools are brilliantly specialized, while others thrive on flexibility. Maybe the real takeaway is that knowing when to reach for each is the mark of a savvy developer. Thanks again for the great discussion, this is why I love sharing on Hackernews, nowhere else has such a density of curious, sharp-minded people who push ideas further.

0cf8612b2e1e 1y ago

I too never get the Excel hate. Without Excel-what do you expect non programmers to do? They sit in front of a computer all day long-would you prefer they use paper? Official IT resources are a joke and will never deliver something so understandable and malleable as Excel. Sure, the official IT app may be done the right way, but it will quickly become outdated as business processes change and the maintenance budget disappears.

bryanrasmussen 1y ago
I mean I hate Excel - for me. Not for anyone else. I think it is a great piece of software and I only wish I could make something as successful. But I definitely hate working with it.

antisthenes 1y ago

> It sounds like Karen did a valuable service to the company. She combined a technical skill set with her domain knowledge to create a system that was so successful that the company now depends on it. Cleaning up the technical debt seems like a task that's well worth the cost. The technical debt here was solved by creating a complex Excel worksheet. The sheet is the solution. For small companies where these Excel monsters get created, it is the #1 best way (read - cheapest) to solve technical debt, which, before Excel, was probably a bunch of arcane manual processes that took 5x as long with worse accuracy.

jdauriemma 1y ago
Good point, though not all spreadsheets are created equal. Some get quite unmanageable, and that can be a productivity bottleneck over time (unless you're not really adding new use cases)
- Ezhik 1y ago
  Maybe the real problem to solve is not killing Excel but providing a pathway for load-bearing Excel sheets to grow into full applications, development practices and all.
  - jdauriemma 1y ago
    I feel like this is doable with a good LLM-assisted coding tool, but it's just a hunch.
  - antisthenes 1y ago
    I think the hardest part here is UI. With Excel you get no-code immediate UI feedback in the cells. Most people will use an Excel sheet as an array or a dataframe.
dalibenothmen 1y ago
Thank you for your comment.Totally get what you’re saying and yeah, that’s a solid take. My main point was more about what happens next when those "Excel-as-solution" systems grow beyond their original scope and start needing maintenance, collaboration, or scale. That’s where things can get tricky. But I completely agree Excel often is the hero in the early stages.

betaby 1y ago

> Excel is one of the most successful pieces of software of all time This is constantly repeated truisms, and yet I don't use it and have no plans using it. I'm certain I'm not alone. Excel is counterintuitive and not 'consumable' as the opposite to SQLite. Surely I understand it not the same. Also I suspect most of the Excel users use it like CVS editor.

TZubiri 1y ago
Tell me what other piece of software gives so much turing-complete power to non-technical users. "Karen" can literally write programs with little training, there's memory, there's functions, there's references, excel is the best.
- betaby 1y ago
  Problem arises when "Karen" leaves the company. Then the company asks the "IT guy" to "help" with that Excel sheet on a shared. Again, as I highlighted Excel sheets is not a 'consumable' software. OK to use for one time things, but in a long run it's most likely a mistake.
  - afiori 1y ago
    Famously Jane's Street started by using excel automation for its core trading business. I do not particularly like excel, I find it interesting but often obtuse and limited in annoying ways and I agree that for an established workflow using "proper" code is generally better. But imho where Excel excels is in dynamic exploration and supporting decision making, where the type of analysis and visualisations you might want to do can change radically and quickly
  - nyeah 1y ago
    We never ever see this scenario happen with code :-)
narcraft 1y ago
Anyone who hasn't used Excel is totally out of touch with reality (constrained to developed world). Excel is counterintuitive to whom? What intuition does it upset? It's a grid of cells. Each cell can reference any other. You can immediately see the definition of any cell when selecting it. I'd wager that it's used as a presentation or modeling tool far more than as a CSV editor. Its dynamic aggregated views, what-if scenarios, charting and dashboarding hardly could be replicated with SQLite or CSV tools alone. Surely not as seamlessly or intuitively as Excel.

fellowniusmonk 1y ago

The real problem is that even though most problems are actually text problems (or can be represented by text chars) we don't have version control with the same level of granularity for spreadsheets.

inetknght 1y ago
Really? What's a database? A spreadsheet. Databases can have version control, backups, etc. And, what's git? A spreadsheet can be committed to git. Version control for spreadsheets? It'd be awesome to have on its own, but it's also not hard to add it on top of spreadsheets' existing features.
- afiori 1y ago
  It is often said that xlsx and docx files are basically zipped folders of XML files and assets, I wonder how effective it would be to add the decompressed forms to git to see and track changes (or similarly for git to show diffs for the files inside a tar/zip
  - thankyoufriend 1y ago
    Not hard at all as it turns out. I had to do this a few years back to extract PBI metadata (metric names, queries, data sources, etc.) from of our dashboards.
- fellowniusmonk 1y ago
  I hope you realize you aren't disagreeing with me. That's exactly my point. It's always interesting to see where developers don't build obvious solutions into existing tool. You're very right that it's not hard, but to me, the fact it hasn't been done, is interesting thing from a sociological perspective. I've seen many code editors with amazing git ergonomics built in, never for spreadsheets. I'm actually working on text only spreadsheet markup that is human intuitive and building interfaces to go with it.

TZubiri 1y ago

"I'm not sure, honestly. It depends on whether you want the fix being done by a resource you consider to be a cost center or a value center. The former will do the cleanup job for bottom dollar. The latter would team up with Karen to amplify the project's impact while cleaning it up." This is not the first time I see developers berating non-technical users, and I like the thesis that they will function as cost-centers that will do a cleanup job instead of teaming up with the user. It's like they will attempt to "do the work" in a binary fashion, making the "correct" choices, often focused on technical factors, like which library to use or what algorithm, instead of focusing on the business domain. I also see this attitude when facing technical issues or bad code as if it wasn't our job to deal with bad code (and as if non-bad code existed)

brendoelfrendo 1y ago

>> ...And when it breaks (not if, when), guess who gets called to fix it? >I'm not sure, honestly. It depends on whether you want the fix being done by a resource you consider to be a cost center or a value center. The former will do the cleanup job for bottom dollar. The latter would team up with Karen to amplify the project's impact while cleaning it up. You're right that the answer is "it depends." In the world of risk management and audit, what Karen has created is called a "user-developed application." Her employer should give her a big pat on the back, and then take a step back to decide 1) if this Excel spreadsheet is mission critical, 2) if it is, who will maintain it, and 3) whether its importance justifies building a formal IT solution to support the business function (either in-house or using COTS software). I agree that Karen did nothing wrong! She found a process that could be improved or automated, and was able to use technology to do it. If someone is caught off guard when the Excel file goes kaput, then that's not Karen's problem nor is it her fault; it's her employer's responsibility to pay attention to their own business requirements.

iLemming 1y ago

> Excel is one of the most successful pieces of software of all time, so it's an odd choice for a punching bag. So is Photoshop and Google Maps - the point of the article isn't bashing on Excel, it's about choosing the wrong tool for a job.

dalibenothmen 1y ago

Thank you so much for this thoughtful comment. I want to start by sincerely apologizing if the analogy came off as dismissive or disrespectful. I didn't mean to diminish from excel at all, in fact, you've highlighted exactly why Excel is so powerful and why my analogy works, just not in the way I originally framed it. Let me clarify what I was trying to get at: Excel's success comes from empowering domain experts like Karen to solve real problems without needing a computer science degree. That's genuinely amazing and valuable. The "problem" isn't Excel itself or Karen's contribution, it's when the tool becomes the permanent solution rather than a stepping stone. My point about visual workflow tools was similar: they're incredibly powerful for rapid prototyping and getting things done quickly. But when professional developers (whose core skill is writing maintainable, scalable code) use them as their primary solution, we might be missing opportunities for more robust, long-term approaches. You're spot on about the value vs. cost center perspective. In Karen's case, the smart move is absolutely to work WITH her domain expertise while adding technical structure. Similarly, visual workflow tools can be fantastic for proof-of-concept or when you need something working yesterday. I think my tone came across as dismissive when I meant to be more reflective about when we choose the right tool for the job. Thanks for pushing back on this, it's made me think more carefully about how I frame these discussions. Both Excel and visual workflow tools have earned their success for good reasons.

jdauriemma 1y ago
I think I might have phrased my criticism too sharply, sorry about that. I wouldn’t have commented if I didn’t think you were making a worthy point though! There was an article about malleable software recently that used avocado slicers vs. kitchen knives as an analogy; the more I think about your piece, the more it resembles that concept. https://www.inkandswitch.com/essay/malleable-software/ https://www.inkandswitch.com/essay/malleable-software/
- dalibenothmen 1y ago
  No need to apologize at all. I really appreciate you taking the time to engage thoughtfully! Your feedback helped me clarify my own thinking, which is exactly the kind of conversation I love. And that avocado slicer vs. kitchen knife analogy is perfect, it captures the nuance so well. Some tools are brilliantly specialized, while others thrive on flexibility. Maybe the real takeaway is that knowing when to reach for each is the mark of a savvy developer. Thanks again for the great discussion, this is why I love sharing on Hackernews, nowhere else has such a density of curious, sharp-minded people who push ideas further.