[raquo]

> Currently anyone can declare himself a software developer

And that's great.

> That largely explains the number of sql injection vulnerabilities, unencrypted sensitive data, unintuitive software UI, unpatched servers, cross site scripting vulnerabilities, and other moronic software design decisions.

No, what explains that is market variety. You want a $200 Facebook clone, you get what you paid for. You want a well built iPhone app for $30000, you'll get what you paid for, probably. No regulations can protect clients from their moronic hiring decisions.

[EliRivers]

You want a well built iPhone app for $30000, you'll get what you paid for, probably.

Yeah, probably. That's not nearly good enough. Not even close. There's an enormous list of extraordinarily expensive failures in the software industry. If I pay an actual professional a serious amount of money to do something for me, and it turns out they did a truly awful job (which is pretty common in the software industry), I expect to be able to claim recompense from their professional insurer and/or their professional licencing body. That's part of why I pay so much; the reassurance. Knowing I can rely on it.

Software, of course, has no such professional body, and exists in a twilight world of chancers and incompetents. Why should the software industry get away with knowingly producing crap and charging a fortune for it?

I'd be happy with a two tier approach; at the moment, if I want a wall built, I can pay a professional (with the expectations and protections that comes with the high price) or hire a day-labourer I met in the pub. There is no such choice in software.

[mtbcoder]

> Software, of course, has no such professional body, and exists in a twilight world of chancers and incompetents. Why should the software industry get away with knowingly producing crap and charging a fortune for it?

This is not really correct. If you are hiring a development firm or an independent contractor, you stipulate in your contract that the company or developer must carry some form of errors and omissions insurance. I've never seen a contract that did not have this line item. Any reputable company or independent contractor will already carry this regardless. If they do not, avoid hiring them.

[raquo]

We have such a two tier approach here in BC with licensed Software Engineers. That's fine by me as long as my own work is not regulated.

But there are only ~200 licensed software engineers in BC, so as far as the general market for software development services is concerned, they are irrelevant outside of niche applications where lives are at stake.

[cm2187]

It doesn't cost anything to not design a sql injection in the first place, or to add a function to encrypt data. The problem is not cost, it is incompetence.

[randomdata]

While I might agree that the tooling for writing injection-free SQL has improved over the years, certainly back in the day you did have to think about edge cases and be mindful that you weren't allowing anything through. That comes at a cost.

Likewise, especially when it comes to encryption, many schemes have been broken over the years by someone just "adding a function". Actually understanding the vectors one might try to attack what you are doing, again, adds cost.

Finally, as cost is directly proportional to the supply and demand, competent people are generally going to be found in lower supply and in greater demand. Even if you discount the above, competent people are naturally going to cost more.

[cm2187]

I would agree if we were talking about much more advanced technologies (like multi-threading or high performance code). But using cryptographic functions or parameterised queries are pretty basic skills. You don't expect every electrician to be able to fix a motherboard but you expect any electrician to know "domestic electrical installation 101".

[randomdata]

> parameterised queries are pretty basic skills.

You might be able to say that now, after much publicization and improved tooling. PHP/mysql comes to mind as not even supporting parameterized queries up to somewhat recent history. Ensuring your queries were safe was entirely up to you. A lot of those old code bases still exist and are being exploited, but what evidence is there that people are still writing brand new projects that way?

That said, even in recent times I've run into edge cases that were not covered by parameterization, still leaving me to ensure the query is sane. It takes care to make sure you get it right. Maybe if you're just shuffling basic user input into a database you can make that claim, but not all tasks are so simple.

> You don't expect every electrician to be able to fix a motherboard but you expect any electrician to know "domestic electrical installation 101".

If you are writing web software you probably should know SQL and all of its shortcomings, but I wouldn't expect all programmers to know SQL, even at a basic level. There are countless programming tasks that will never have anything to do with relational databases.

[raquo]

You don't just pay for the number of hours, but for competence too. That's the point.