Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I'd rather have a multiple generations more mature software industry at a point I'd need to develop "safe" software, than a safely evolved industry several generations behind.

Yes, that's exactly the problem. So now we have an unsafe industry that is producing a terrible that powers a very large chunk of the worlds commerce. It's a house built on quicksand and our hope seems to lie in hoping that we can move to another house before this one collapses.

The areas in which this is most visible: security, reliability, maintainability, documentation and testing, and finally a complete lack of warranty for suitability from the various manufacturers/service providers.

Software is 'eating the world', but is it strong enough to support the world in the longer term if we continue down the road that we are on? I'm not bullish on that.



Let me start off with saying I completely agree with your points of the downsides of this.

It is however extremely hard to imagine the world that would be, if we were to take a different route. What would be the effects of slower improvements. I assume (since I sometimes do) many people look at the software industry as narcissistic and self-agrandizing when "delivering expriences" and "solving global problems with scalable midware". But what third party industries would be held back if this one moved much slower? Could there be loss of medicinal advancements, monetary, safety, third world advancements?

But as you say, I'm also very hesitant on the stability if we can't find some middleground between the two.


To borrow a line from Larry Page's book: more wood behind fewer arrows. That would already work wonders, so instead of having an endless repeat and rehash of the same concepts in disposable form it would likely be better (and possibly even faster, so no effective slowdown!) to do things a bit better, to try to merge more often rather than to fork and re-start all over.

I think the feeling of fresh and new development (before complexity sets in) is so compelling that it tends to drive us away from actual progress. After all, it is so much easier to launch yet another half-baked language, frame work or product than it is to pick up something existing and to really improve it or to update it in a way that it will last much longer. That's relatively thankless and anonymous work compared to slapping your handle on a new framework.

This is part of what makes good software hard: good software isn't sexy (think: erlang verus node.js, as just an example, I've tried very hard to keep this discussion brand and tech free but I feel that an example may help to illustrate what I'm getting at).


For reliability, I think the Jepsen approach of an expert stress tests a system and reports on where it fails is a good approach. I see some "big data" vendors actually pay him now to analyze their software, then fix the bugs he exposes.

Security bug bounties are also an important advance in software engineering process.

I also think there is a growing interest in these issues outside the industry. For example, we are likely to have as our next President someone all too familiar of the risks of poorly secured email systems. Maybe this will be the impetus for a more serious focus on security, at least.


Jepson is awesome.

Bug bounties are not such a hot idea in general. There is the issue of entitlement on the white hat, disputes about severity levels, potential for blackmail, and the two engineers that are clearing the false positives. Better to put them in the pen test team.


I might dispute bug bounties, which are nice in theory but can be a nightmare in practice, and have a somewhat limited upside.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: