@thegibson I think it would help if:
- there was actual liability for commercial software and hardware providers; I don't fscking care why the bugs are there, it's your product, you're accountable.
- annual NSA/CIA dark cyber budget of ~50bln USD was redirected to US-CERT instead (and similar moves were made in EU/UK), which currently gets ~100mln annually.
- those agencies were otherwise required to report and help fix vulnerabilities they found, instead of hoarding them.
@thegibson "all software has bugs" is the "boys will be boys" of the tech sector.
It pretends to explain and justify the state of affairs.
IT is infrastructure. Somehow we can have bridges that don't crumble when a teenager sneezes on them funny. We should be able to have IT infrastructure just as stable. It's not rocket surgery, it's just lack of incentive.
@rysiek @thegibson there is differences between bridges and programs. the function of a bridge is well defined, and the laws of physics don’t change over time. our understanding of them may change, construction techniques may improve; but the final “test” is immutable .
but the function of a computer program is usually poorly defined vague waffling from a middle manager, if there is an equivalent “laws of computing” they’re poorly understood, and programming techniques go in fashion cycles.
@zens @thegibson seems like the problem is not defining the function well enough. If you're saying we need to fix this and make sure software functions are well-defined when used for critical infrastructure, I am there with you.
If you are using it as an "argument" to make it seem fixing IT is impossible, you're making the problem harder to fix.
One wonders what would happen if some Microzon Facegoople drone was as responsible for their product not failing catastrophically as construction crews are for bridges not falling. I am talking hard jail time.
Would that incentivise them to find good ways of defining the scope of the project better?
We should abandon the designation Software Engineering and stick to programming or development, until the industry writes software to meet national safety and reliability standards that are enforced by a system of inspections of plans, the process and final code.
That's why engineering is so reliable - software development hasn't advanced to the level of engineering yet.
@minoru @rochelimit @khm @rysiek @thegibson i think the question of whether software devs are “engineers” really comes down to certifications, oaths, and agreements. I found out the other day that most doctors don’t take a hippocratic oath! but for lawyers, and doctors there’s a bar, specifically so they can be disbarred. engineers have a ring
software devs don’t have this, and it’s kind of urgent that we do like this to self regulate, orherwise governments will.
@minoru @rochelimit @khm @rysiek @thegibson but i will sound like a broken record again and reiterate my original point: only a tiny minority of software dev resembles engineering, e.g. control systems, network comms, kernel development. the rest is the extremely political act of turning all human life into formal logical statements, to decide things like whether someone “deserves” to get a welfare check
@zens Yeah, licensing is the most common counter-argument to claims that software engineering exists. There is a good counter-counter-argument to it in the first post of the Crossover Project. Do read about the project; it's just two posts, and they're pretty insightful.
I read the Crossover article - thanks for the pointer.
I still don't agree with the conclusion though, since the article discusses the process similarities between 'trad' engineering and software engineering without discussing the most common definitions.
although Engineering or Physical Science degrees seem universal.
No, I see engineering as the application of physics or maths principles in the design of solutions. Software engineering sits closer to social engineering in the use of the term. (engineering with a small 'e').
@zens @khm @rysiek @TheGibson @minoru - 2/2
@rochelimit But the whole project exists precisely because there are no definition of "engineering". The first post starts off stating: just like with porn, you know engineering when you see it. Or do you have some other definitions in mind?
College/uni degrees are indeed a bit of an indicator. I never heard of anyone landing a "trad" engineering job after a three-months-long bootcamp. Never even heard about the existence of such bootcamps.
I take it you don't buy Hillel's argument regarding discrete maths? And you disagree with his parallels to electricians vs. EEs?
(I dropped the topic starter from mentions to stop spamming them — they never replied here).
Engineers are regulated in 84% of EU countries, generally under the EUR ING accreditation process. Almost all nations have a similar degree plus minimum years of practice requirement for certification, generally coordinated by FEANI. Of course each nation has its own governing body for accreditation.
@khm The Crossover Project highlighted that software as a field is much more open: devs know not just what their colleagues are doing, but also what FAANG is doing, what startups are doing, what FOSS are doing. It could be argued that this level of awareness replaces regulations somewhat. I do realize these are not completely equivalent, though.
(I dropped the topic starter because they never responded in this thread).
@minoru @rochelimit @zens @rysiek Forgive me, but I don't think the development world is as open as people believe it to be. Goals and projects might be open, but the amount of irresponsibly-bad software in the world never seems to decrease -- especially in the embedded and mobile spaces.
In the end, if a bridge collapses and kills people, there is a custodial chain of responsibility for that. Visibility can enable accountability, but not replace it.
to clarify my position, I don’t *actually* believe that accreditation can magically turn software inro engineering. I maintain that software is, ar its core, *not* engineering; though certain specific cases of software, instances where the problem is well defined and the outcomes measurable, can have engineering applied. (e.g, network programming, which has an element of real physics to it)
rather, “engineering” is a giant red herring here, when what we really care about is safety and security. The core belief is that if some “good” software was better defined and regulated, and “bad” software made harder to sell and/or distribute, things like ransomware can be avoided. trying to claim this “goodness” is “engineering” and then defining what engineering is, is a distraction.
This conflates the thing itself from the use of the thing.
If I build a wooden house, and the buyer tries to land a jet on it, that's not an engineering failure, but pilot error.
If I am hired to design an aircraft carrier, and I specify it to be buit from matchsticks, I have demonstrated incompetence and should be prohibited from practice.
The epistemology of engineering is irrelevant; programmers are simply unaccountable for their work output.
the closest thing we have is @jepsen as a way to compare databases, and decide which one suits your needs
but we have nothing like that for programming languages, libraries or API
And yes, I completely agree. Things like fuzzing, ChaosMonkey, and unit tests are kinda sorta steps in the right direction, but we're way at the beginning of that road.
LANGSEC ( http://langsec.org/ ) and reproducible builds movement are another important steps in the direction of IT infrastructure reliability. We need more of these.
I am hereby stealing this take, for it is a good take, and illustrates an important part of the problem. 😉
Seriously though, this hits one of the nails right on the head!
(dropped a person who is not interested in this conversation)
which API is a steel beam, which one is a dry wall?
we can't tell anything, because everything is just ✨ an opinion 🎉
and to a certain extent, when it comes to the ergonomics of programming, that may be true
but the amount of security issues unergonomic APIs (👀 OpenSSL) have q caused is truly mind boggling
And it gets worse: sometimes even after we kind of sort of figure out that a particular technology stack is somewhat brick-shaped rather than match-shaped, a few years later that technology stack is dismantled or deprecated for some odd reason.
Python 2.x is an example here. It's not a perfect language, but it was reasonably good at being infrastructure when used correctly, and was reasonably well understood. So a lot of stuff was built in it.
1. it is clear we have not achieved "software flabgraffity" yet
2. we need to figure out how to achieve "software flabgraffity"
And I am pretty sure once we start sketching out what "software flabgraffity" looks like and how to achieve it, it will start looking suspiciously "engineering"-shaped.
In the meantime, most of what you said in this thread seems to be "it's impossible to make software safe"; perhaps that is true, but in that case, I hope you agree software should not come anywhere close infrastructure.
Would you agree with that?
@rysiek @khm @minoru @rochelimit
my position is more that, yes, software can be engineered, and can be made safe, but only a tiny miniscule subset of it. the subset that resembles a maths problem or an engineering problem. most software, to repeat myself, are codified political starements about the human world; self contradictory and brittle against the complexity of reality.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!