Live data from Hacker News

How would we regulate software engineers?

tavisharmstrong.com

41–50 of 60 posts

Re: How would we regulate software engineers?

#41
How would we regulate software engineers? Badly.

We don't yet know how to reliably balance desirable goals in software development, such as delivering a certain level of quality and reliability, or delivering on time and on budget. That immediately undermines aspects such as proof of competence or ongoing training that are usually associated with regulated professions.

Moreover, I imagine the people in the industry who would be closest to getting these things right are probably too busy working on building real systems to spend much time teaching or assessing. If government officials started trying to set up a professional accreditation scheme for software developers with real legal weight, how many people here seriously believe the result would not be exams in Agile Software Craftsmanship Manifesto Driven Development, written and assessed by high profile and no doubt highly paid consultants whose total contribution to actual working code in high reliability or otherwise important systems is less than the contributions of at least half the people reading this comment?

We're not ready yet. With luck, we might be within at least some of our lifetimes, but I wouldn't bet much money on it. And in the meantime, any attempt to set this up would surely be subject to instant regulatory capture by exactly the kind of vultures our industry needs to move away from if standards are going to improve.

Re: How would we regulate software engineers?

#42
post #30
post #11

Earlier quoted context omitted.

The ethical and competency attributes are still relevant. Particularly with respect to actual engineering (architecture of the overall solution) aspects of logic systems development and deployment.

I think one of the main problems with ethics is the abstract nature of software and development. Let's say you create an encryption algorithm. That algorithm can be used by terrorists and pedophiles or it can be used by banks and civil disobedients. Or let's say you create an encryption breaking algorithm. That algorithm can be used by law enforcement and the judicial system or it can be used by identity thieves and…

This kind of argument applies to anything, even paper. Encryption is just a tool. A pipe can be used to hide and carry water, it can also be tampered with to poison someone or conceal explosives.

Re: How would we regulate software engineers?

#43

How would we regulate software engineers? Badly. We don't yet know how to reliably balance desirable goals in software development, such as delivering a certain level of quality and reliability, or delivering on time and on budget. That immediately undermines aspects such as proof of competence or ongoing training that are usually associated with regulated professions. Moreover, I imagine the people in the industry w…

> how many people here seriously believe the result would not be exams in Agile Software Craftsmanship Manifesto Driven Development

Well, since the sort of people who set up regulatory exams are likely to be the same sort of people who design college curricula, I don't think that would be the case at all. I suspect that a software licensing exam would cover things like algorithmic complexity, NP-completeness, pushdown automata, Turing completeness, LR parsing, etc. etc.

Re: How would we regulate software engineers?

#44
post #28
post #6

I have some engineering background and you only have engineers in stable predictable fields. You can predict quite accurately the failure load of a bridge truss or a transistor and its easily testable and the whole process can be simulated and verified top to bottom. My guess is the wedge to bring in engineering would be network operations, classic operations (not devops which just means we're gonna pencil whip the o…

You can make software a predictive profession, by adding an order of magnitude of cost to every software development effort. 10x. It's not that it can't be done. It's the market is not suitable for that sort of development. It's a management problem, not a software engineer problem. There are a huge number of combinations of various statements that have to be iterated over meticulously. If you want to write tests for…

"You can make software a predictive profession, by adding an order of magnitude of cost to every software development effort. 10x. "

This is a recurting myth. The field of high-assurance software delivers it on a regular basis in regulated markets. They built tools and reusable modules that drove costs down a lot. Still high cost vs throwing crap together.

So, methods were invented far as the 80's to get most of those benefits on the chesp. Cleanroom methodology got very low defects with cost modifier ranging from cheaper to 20 or so percent more extra. That debugging & hard-to-change codd were greatly reduced offset upfront cost. LOCK secure kernel reported about 38% extra cost with full, formal verification & leak prevention. Altran/Praxis does it today for their clients with a mix of Z, Ada, and SPARK for claimed 50% premium. None of these are "10x" higher. Maxed out at 1.5x for most. Market can bear that.

Only proven weakness of highly-assured development is time to market. Features do take longer to build if verified thoroughly. Medium-assurance like Cleanroom has some slowdown but acceptable. Less debugging and breakage by extensions offsets that, too.

Re: How would we regulate software engineers?

#45

You'd better spend your time, by regulating things that generate code and validating/regulating that output.

Look up DO-178B market. They regulate the software lifecycle itself requiring evidence each part is handled. After source is analyzed and tested, they also do source-to-object code verification. Tools that generate code have to be similarly qualified as you said. An example done by a top company in the domain is below:

http://www.eecs.northwestern.edu/~clk800/rand-test-study/_er...

Re: How would we regulate software engineers?

#46
post #20
post #15

Earlier quoted context omitted.

Is there a universally or even widely accepted difference?

The difference between software developer and software engineer is ~$10k. http://www.payscale.com/research/US/Job=Software_Developer/S... http://www.payscale.com/research/US/Job=Software_Engineer/Sa...

lol, you realize that none of the Google "software engineers" are accredited?

Google Canada calls their employees software developers. Everyone would just call themselves a different name and life would move on as nobody cares.

Re: How would we regulate software engineers?

#47

Earlier quoted context omitted.

There are regulations that affect the work of software engineers. PCI DSS is one that I am familiar with. Perhaps unfortunately, if your software interacts with the real world (like payments infrastructure), you have to heed regulation. This tends not to affect people who are casually writing software or working on many open source projects, but it does impact large companies like Google. (I like to think of this as…

PCI DSS isn't regulation. It's a standard promulgated by a private LLC (the Payment Card Industry Security Standards Council). HIPAA would be a much better example of regulation that is material w/ respect to software development.

Great point. Thanks!

Re: How would we regulate software engineers?

#48
As to the discriminatory and societal problems you write about, I don't know.

But there are certainly standards for particular fields of applications, like medical IT, enforced through stricter liability laws in that field.

In the 1990's and 2000's there was also a very long push for standardization (POSIX/SUSV, programming languages, SQL, SGML/XML, IP protocols, etc.). These efforts (and the success of Java) was also seen as a measure against Microsoft becoming predominant in the 1990's by many developers.

But in this decade, it seems like this isn't anymore a priority. A guy here on HN recently wrote that he'd never consider a language environment lacking a "canonical" or solitary implementation (like, say Ruby, Python, PHP, Perl, or other languages tied to their runtimes have). I found this very interesting, as it's the opposite of what I'm doing (I use only use languages having a language spec and multiple implementations).

I also see it as a generational phenomenon. Look at node.js today. Back in 2011 or so it started as a really practical asynchronous server-side JavaScript runtime based roughly on CommonJS platform specs also implemented by other JS runtimes. Nowadays, the entire reason to use JS in the first place, its ubiquity/portability, is completely lost, and node.js build setups are approaching or even surpassing J2EE-ish levels of complexity/absurdity (webpack, babel, angularjs, etc.).

Re: How would we regulate software engineers?

#49

How would we regulate software engineers? Badly. We don't yet know how to reliably balance desirable goals in software development, such as delivering a certain level of quality and reliability, or delivering on time and on budget. That immediately undermines aspects such as proof of competence or ongoing training that are usually associated with regulated professions. Moreover, I imagine the people in the industry w…

> how many people here seriously believe the result would not be exams in Agile Software Craftsmanship Manifesto Driven Development Well, since the sort of people who set up regulatory exams are likely to be the same sort of people who design college curricula, I don't think that would be the case at all. I suspect that a software licensing exam would cover things like algorithmic complexity, NP-completeness, pushdow…

Well, since the sort of people who set up regulatory exams are likely to be the same sort of people who design college curricula, I don't think that would be the case at all.

OK, you win. There actually would be a worse option than letting the consultants do it...

Re: How would we regulate software engineers?

#50

The first thing needs to be a culture change: "move fast and break things" is not an acceptable philosophy when you're dealing with millions of people's private conversations.

OP here. I work at a company that is able to move quickly, and yes, sometimes breaks things in the process. Tradeoffs between speed and safety are fine to make, in my opinion. It does seem like it would be useful to regulate things like ethical conduct, though. Maybe this dictates what systems are ok to move quickly and break and which systems aren't. What do you think?

[deleted]
Post reply on HN