Hacker News Reader

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.

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.

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.

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/

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.

Genuinely very curious: are you finding that meaningful numbers of experienced developers are turning to these visual workflow tools instead of writing code for substantial use cases?

I was a bit confused by the post because it seems to be written about a persona that I haven't personally come across: professional developers who choose visual workflow tools as a primary solution over building with code the "right way".

I'm still a bit confused because you make broad statements about these tools and their users while actually you seem to be focused on this specific subset of users. e.g. when you talk about why these tools are successful, was your intent to limit the scope of your comments about the success of this category to just professional developers?

In a separate comment, I criticized the post before I fully realized you're specifically talking about developers, and not the typical audience for these products. I'm trying to understand if that's the lens through which the entire post should be interpreted. If so, making that more clear would strengthen the post I think.

I'm still a bit skeptical about the existence of said persona, but happy to be shown I'm wrong.

That's a really fair question, and you're right that I could have been clearer about the persona I'm addressing. I'm actually part of that audience myself! As a developer and automation enthusiast, I fell in love with tools like Zapier and n8n, they're genuinely great for getting things done quickly. I still use them today for certain use cases. But here's where I've noticed the pattern: I've seen experienced developers (myself included) increasingly reaching for these visual tools even for complex workflows where code would be more appropriate. The tipping point for me was when I found myself building workflows that required custom scripts within the visual tools, dealing with 3-5 second execution times, and accepting limitations that I could easily solve with a few lines of code. You're absolutely right that the typical audience for these products isn't professional developers and it's business users, which is exactly why these tools are so successful and valuable. My frustration (and the motivation for this post) comes from seeing developers including myself choose the visual approach when we have better alternatives. This experience actually led me to build a code-first workflow automation engine with Bun and Rust that can handle computational-heavy workflows in milliseconds rather than seconds, at a fraction of the cost. I can even run it in a 1vcpu, 1GB ram VPS and still get a great performance. I think you've highlighted exactly why the post felt off, I was conflating the general success of these tools (which is well-deserved for their target audience) with a specific developer behavior that perhaps isn't as widespread as my bubble made it seem. Thanks for pushing me to clarify that distinction.

> 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.

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)

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.

I feel like this is doable with a good LLM-assisted coding tool, but it's just a hunch.

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.

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.

>> ...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.

"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)

> 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.

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.

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.

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

We never ever see this scenario happen with code :-)

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.

Agreed, it has permeated every single industry in the developed world. Professional software developers have been known to reach for it, in a pinch, over dozens of other known and much more powerful tools.

The immediate feedback and visual layout make it the definition of "killer app." Jupiter notebooks has been trying to replicate the magic for years. Entire businesses and industries are built around selling products to successfully replicate what was originally living in a spreadsheet somewhere.

> I don't use it and have no plans using it. I'm certain I'm not alone.

Too easy to refute. Treating "Excel" as actually "spreadsheet processing," the software has been so consistently and hugely popular that everything from early PDAs [0] to Google Sheets / iCloud Numbers has supported it. Every type of personal computing device has it, from graphic calculators [1] to laptops to tablets to PDAs to many cell phones.

> I suspect most of the Excel users use it like CVS editor.

Like some classes of addictive chemical compounds, you may start with this but quickly find it is the gateway to other habits.

[0] https://en.wikipedia.org/wiki/HP_95LX

[1] https://education.ti.com/en/software/details/en/139B977E62CB...

I don't see how that matters. XYZ can still be the most successfulest even if you don't use it. Even if 1,000,000 people don't use it.

I feel like I'm hearing "Hundreds of people who don't like Elvis can't be wrong". And I don't even like Elvis!

> 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.

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.

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.

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

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.

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.