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

> codified standards for how to do things

I don't know you but i bet that if you and me were locked up in a room together for a month we wouldn't be able to 100% agree on "codified standards for how to do things" :)

Industry isn't mature enough for that and it's perhaps doubtful that it will ever be. See the halting problem.



> 100% agree

I don’t think it’s necessary to agree completely. You could start by codifying a minimal set of things that the majority of people agree on (user data sanitisation, authentication handling etc) and then build on it over time.

The standards could also help codify more meta things, like vulnerability policies, reporting and outages. This would be helpful to form a dataset which you can use to properly codify best practices later.

The main problem is that this increases the bar for doing software development, but you can get around this by distinguishing serious software industries from others (software revenue over a certain size, industries like fintech, user data handling etc)


ye gods, can we come up with a "law" to describe appealing to the halting problem?

Just because there are unanswered questions that doesn't mean we can't have bare minimum codified standards.

Furthermore, standards aren't invalidated just because practitioners disagree with them. Plenty of <insert engineer type>s disagree with the standards body of their respective field, they still follow the standards out of fear of prosecution or simply as a path of least resistance and when those standards are found to be defective, they (generally) evolve.


> we can't have bare minimum codified standards

So, functional, imperative or OOP? :)

> Just because there are unanswered questions

The halting problem is undecidable. Not undecided. I.e. it has been solved and the answer is "you can't".


This is the most pedantic sort of semantic navel-gazing that can only originate in the bowels of an HN thread. Bravissimo, truly.


Yep, now answer me the part about functional, imperative or oop, and come up with a plan to convince everyone.


We don't need to solve the halting problem. We just need to come up with a sensible set of practices that, if followed, make the risks small enough to be considered acceptable. Then we can point at that list and say, "this is what the reasonable expectation of due diligence in software engineering is" - and legally enforce that.


The industry will be 80 years old soon. If it's not "mature enough", it's only because of the pervading culture.

For comparison, electrical engineers started introducing things like national standards for plugs by 1915.


Plugs? You mean various forms of rpc and more or less well specified data interchange formats like xml or json? We have them.


XML and JSON is more like standardizing the voltage (and even there the fact that we still have both shows that it's very much a moving target).




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: