Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on slowing the fuck down

mariozechner.at

Post reply on HN
Print view View original

121–130 of 505 posts

Re: Thoughts on slowing the fuck down

#121

Post by wat10000 »

dstroot wrote: post #99
badlibrarian wrote: post #5

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt? People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understand…

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was. If I engineer a bridge I know the load the bridge is designed to carry. Then I add a factor of safety. When I build a website can anyone on the product side actually predict traffic? When building a bridge I can consult a book of materials and understand how much a material deforms under load, what is breaking point…

I think it is in certain very limited circumstances. The Space Shuttle's software seems like it was actually engineered. More generally, there are systems where all the inputs and outputs are well understood along with the entire state space of the software. Redundancy can be achieved by running different software on different computers such that any one is capable of keeping essential functions running on its own. Often there are rigorous requirements around test coverage and formal verification.

This is tremendously expensive (writing two or more independent copies of the core functionality!) and rapidly becomes intractable if the interaction with the world is not pretty strictly limited. It's rarely worth it, so the vast majority of software isn't what I'd call engineered.

Re: Thoughts on slowing the fuck down

#122

Post by michaelbarton »

jaffee wrote: post #16

> You installed Beads, completely oblivious to the fact that it's basically uninstallable malware. Did I miss something? I haven't used it in a minute, but why is the author claiming that it's "uninstallable malware"?

Malware might be a bit of stretch but could refer to this issue?

https://github.com/steveyegge/beads/issues/1857

Re: Thoughts on slowing the fuck down

#123

Post by hackertyper69 »

0xbadcafebee wrote: post #2

> it sure feels like software has become a brittle mess, with 98% uptime becoming the norm instead of the exception, including for big services As somebody who has been running systems like these for two decades: the software has not changed. What's changed is that before, nobody trusted anything, so a human had to manually do everything. That slowed down the process, which made flaws happen less frequently. But it w…

It's a systems engineering job. You need to provide context, acceptable failure modes, and test at each level for validation. Identify false coupling, poor interfaces, things that don't match business context during agent planning phase. Then communicate / translate to others so their decisions improve instead of destroying the system by optimizing only for their local situation.

Re: Thoughts on slowing the fuck down

#124

Post by Towaway69 »

What the article doesn't touch on is the vendor lock-in that is currently underway. Many corps are now moving to an AI-based development process that is reliant on the big AI providers.

Once the codebase has become fully agentic, i.e., only agents fundamentally understand it and can modify it, the prices will start rising. After all, these loss making AI companies will eventually need to recoup on their investments.

Sure it will be - perhaps - possible to interchange the underlying AI for the development of the codebase but will they be significantly cheaper? Of course, the invisible hand of the market will solve that problem. Something that OPEC has successfully done for the oil market.

Another issue here is once the codebase is agentic and the price for developers falls sufficiently that it will significant cheaper to hire humans again, will these be able to understand the agentic codebase? Is this a one-way transition?

I'm sure the pro-AIs will explain that technology will only get cheaper and better and that fundamentally it ain't an issue. Just like oil prices and the global economy, fundamentally everything is getting better.

Re: Thoughts on slowing the fuck down

#125

Post by angrydev »

BloondAndDoom wrote: post #113

This aligns with my observation from product design point as well. Product design has a slightly different problem than engineering, because the speed of development is so high we cannot dogfood and play with new product decisions, features. By the time I’ve realized we made a stupid design choice and it doesn’t really work in real world, we already built 4 features on top of it. Everyone makes bad product decisions…

Agree. The issue was never, how can we get our engineers to squirt out more lines of code in a day? It has always been, how can we effectively iterate using customer feedback to deliver the highest quality product. That type of thing needs time to bake.

Re: Thoughts on slowing the fuck down

#126

Post by bonoboTP »

apical_dendrite wrote: post #8
ex-aws-dude wrote: post #4

Eh I think its self-correcting problem Companies will face the maintenance and availability consequences of these tools but it may take a while for the feedback loop to close

Unfortunately, I think the lesson from recent history seems to be that outside of highly-regulated industries, customers and businesses will accept terrible quality as long as it's cheap.

Yes, every slack is optimized out of systems. If something has an ounce more quality than would suffice to obtain the same profit, it must be cut out. It's an inefficiency. A quality overhang. If people buy it even if it's crap, then the conclusion is that it has to be crap, else money is left on the table. It's a large scale coordination issue. This gives us a world where everything balances exactly near the border where it just barely works, for just barely enough time.

Re: Thoughts on slowing the fuck down

#127

Post by parliament32 »

dstroot wrote: post #99
badlibrarian wrote: post #5

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt? People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understand…

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was. If I engineer a bridge I know the load the bridge is designed to carry. Then I add a factor of safety. When I build a website can anyone on the product side actually predict traffic? When building a bridge I can consult a book of materials and understand how much a material deforms under load, what is breaking point…

> can anyone on the product side actually predict traffic

Hypothetically, could you not? If you engineer a bridge you have no idea what kind of traffic it'll see. But you know the maximum allowable weight for a truck of X length is Y tons and factoring in your span you have a good idea of what the max load will be. And if the numbers don't line up, you add in load limits or whatever else to make them match. Your bridge might end up processing 1 truck per hour but that's ultimately irrelevant compared to max throughput/load.

Likewise, systems in regulated industries have strict controls for how many concurrent connections they're allowed to handle[1], enforced with edge network systems, and are expected to do load testing up to these numbers to ensure the service can handle the traffic. There are entire products built around this concept[2]. You could absolutely do this, you just choose not to.

[1] See NIST 800-53 control SC-7 (3)

[2] https://learn.microsoft.com/en-us/azure/app-testing/load-tes...

Re: Thoughts on slowing the fuck down

#128

Post by kerblang »

badlibrarian wrote: post #5

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt? People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understand…

Engineering is two things:

1. Applied physics - Software is immediately disqualified. Symbols have no physics.

2. Ethics - Lives and livelihoods depend on you getting it right. Software people want to be disqualified because that stuff is so boring, but this is becoming a more serious issue with every passing day.

Re: Thoughts on slowing the fuck down

#129

Post by pixl97 »

latchkey wrote: post #74
bikelang wrote: post #40

Earlier quoted context omitted.

Were people reviewing your hobby projects previously? Were you on-call for your hobby website? If not - then it sounds like nothing changed?

This is my business website.

[Note: It may be very risky to submit anything to this users site]

I'm not sure doing silly things, then advertizing it is a great way to do business, but to each their own.

Re: Thoughts on slowing the fuck down

#130

Post by PaulHoule »

Towaway69 wrote: post #108
skybrian wrote: post #87

Earlier quoted context omitted.

People don't realize how much software engineering has improved. I remember when most teams didn't use version control, and if we did have it, it was crappy. Go through the Joel Test [1] and think about what it was like at companies where the answers to most of those questions was "no." [1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

At the same time, systems have become far more complex. Back when version control was crap, there weren't a thousand APIs to integrate and a million software package dependencies to manage. Sure everything seems to have gotten better and that's why we now need AIs to understand our code bases - that we created with our great version control tooling. Fundamentally we're still monkeys at keyboards just that now there a…

Perrow’s book Normal Accidents postulates that, given advances which could improve safety, people just decide to emphasize throughput, speed, profits, etc. he turned out to be wrong about aviation (got much safer over time) and maritime shipping (there was a perception of a safety crisis in the late 1970s with oil tankers exploding, now you just hear about the odd exceptional event.)
Post reply on HN