Hacker News Reader

Comment by rglullis | Hacker News Reader

You are taking my comment way too literatlly.

The point is not that people will be using specifically Excel, but that most business only pay for software because it is the tool that gives them the most power to automate their processes. They don't need high availablility, they don't need standards compliance, they don't extensive automated tests, they won't need cloud engineeers and SRE... all you need is some tool that can get the results your are looking for right now.

Academia already works like this. Software wrtiten for academic purposes is notoriously "bad" because it is not engineerd, but that doesn't matter because it is good enough to deliver the results that researchers need. Corporate IT will also start looking like this even at mid-sized companies.

View on HN

I don't disagree with anything you say here - using a tool that lacks guardrails is fine for a lot of tasks, but if that's the only tool and used where those guardrails go from "nice to haves" to something more critical is where the problem is.

I've been in ops for a long time and have encountered far too many "our IP addressing plan is just a spreadsheet with manual reconciliation".

I truly wonder if Excel and all it's predecessors and direct clones (Google Sheets, etc.) are holding back industry from making something truly better and more reliable.

> holding back industry from making something truly better and more reliable.

What "industry"?

If you are talking about the software industry, then I'd say you are creating a circular reasoning. If you are talking about all the other things that we actually need to do and which only incidentally have become too reliant on software to do it, then see back my original point: people don't need "better and more reliable" software to keep running their businesses.

If running your business to '90s standards is acceptable, sure, you can use AI to automate your manual processes with the same error rate and keep doing the same thing indefinitely.

But if the competitors have real software engineers and have used them to actually improve reliability, you'll be left behind.

What software engineers are being hired to work on:

    - A facilities management company
    - A bar/restaurant with a staff of 8
    - An Architecture office
    - A Law Firm with 10 associates
    - A day care
    - A car repair shop
    - A cement factory 
    - A family-owned hotel 
    - A conference/event organizer
    - A video production crew
    - A roofing company

Ok, but if your competitors are getting/using software from a supplier who has real software engineers, and using that to operate at a higher level of reliability, then the same argument goes through.

Sorry, but that logic is pure cope.

If you want to go down the value chain, then by definition the less valuable the software is and the easier to be commoditized. The automation is not going to help just the manager-turned-vibecoder, it's also going to help professionals to create FOSS alternatives that can be robust enough.

It's not going to happen overnight, but the trend is there.

> If you want to go down the value chain, then by definition the less valuable the software is and the easier to be commoditized.

I'm not sure that holds for what we're talking about - high-value software can afford to be somewhat flaky because it delivers enough value when it works to make up for it, software that's only marginally worthwhile needs to be reliable because if it isn't then it's not worth the bother. Commoditized fields are more competitive.

> The automation is not going to help just the manager-turned-vibecoder, it's also going to help professionals to create FOSS alternatives that can be robust enough.

Not convinced. In my experience these tools don't really help with creating high-quality software. Maybe they'll get there eventually (at which point we're all out of a job), but right now they can't "hit the high notes".

> Commoditized fields are more competitive.

Doesn't that also lead to the conclusion that "software engineers" are going to lose their ability to command high salaries, if the real value is in the domain expertise and not in the ability of optimizing some part of the business process?

> Doesn't that also lead to the conclusion that "software engineers" are going to lose their ability to command high salaries, if the real value is in the domain expertise and not in the ability of optimizing some part of the business process?

I mean the job has always required both - just being good at leetcode isn't enough to get paid well (except perhaps where there is a dysfunctional interview process), the key skill is being able to translate back and forth between the world of software and the world of business. Regular folk seemingly still find it difficult to think rigorously, in the way that fully correct automation requires, and AI hasn't actually helped with that any, so I think people with that skill will still command a premium. Work that doesn't benefit from rigour - being able to slap together a quick marketing site on wordpress or what have you - will pay badly if at all, but that was already the low end of the industry I think.

An academic paper needs to deliver its output once, for the research. Maybe someone will try to replicate it later but that's someone elses problem (and fairly often proves the output of the former to be wrong)

Some stuff in companies might be similar, but there's a lot of things that people use every day, in a lot of different ways, and the software needs to work correctly regardless. You can't just drop it like a hot potato once you've built processes around it.

As always, the first 80% takes 20% of the time/effort, the last 20% takes the other 80%.

Reply on news.ycombinator.com