Reading some of the replies I'm shocked. How do we go from the proposal that adopting reasonable standards and practices with regard to software development is a noble goal to mandatory or regulatory edicts requiring standards compliance?

If each of us decides to "do the right thing" regarding the adoption of standards others will follow suit. I know that altruism is probably a dated concept, but come on. We each have an opportunity to lead our industry in more than just salary and perks - we can lead by setting an example for others to follow and by adopting the good examples set for us by others within our workplace, field of expertise, and industry.

Start small - what about documenting your work so the next guy (or future you) knows what's going on without having to spend exhaustive hours pouring over the code to figure it out? And if you're that guy that's doing the exhaustive research into a predecessor's work, document it while you're at it so the next poor schmuck that has to deal with that code will bless you rather than curse you.

This should not require Herculean effort - it should only require that we decide to do it and then follow through. We decide, we don't wait for an external agency or regulatory body to make these decisions. It's up to us.

Because families don't drive cars over most of our software with certain death below.

Its important not to paint all development with the same brush. Tree forts don't get designed and built the way houses are. No one consults an engineer before using a fallen tree to cross over a stream.

In MOST things (not just software), the quality and care that goes into the end result is a factor of the parameters around what is required.

So things like air traffic control or manufacturing or power generation get engineered to high standards (I hope)

With commercial software, it is really like any commercial product. The standards to be met are defined/enforced by the consumer and that is the only thing forcing people to develop better. This is obviously not ideal (as quality problems and shoddy work can be tough for an end user to discern), but that issue is hardly unique to software development. Only real answer there is to have some sort of trusted standards organization for software going in and certifying code. But even the demand for that would have to come from the customer.

And then a heck of a lot of programming/DB work that gets done is in a completely seperate (and totally chaotic) bucket of other things. Custom little scripts and databases and interfaces and tools to make simple repetitive business tasks easier or more organized or in some way better. This is often a wild west, but then again its often not a trained professional doing it, and even when it is, they are given zero time and zero budget and the consequences of doing it wrong are nil. So applying proper practice to a little app that will be used for a year and replaces a spreadsheet and with little impact/risk would actual make it not worth doing at all.

In some ways the comparison to bridge building is a good one and in others it's a bad one. If the company that was contracted to do the concrete work mixes things improperly, the bridge is going to start falling apart way sooner than it should. Even bridge building can have missing or misunderstood requirements, such as poor capacity planning, or even not understanding the environment that the bridge is built in. (take a look at http://www.wsdot.wa.gov/tnbhistory/connections/connections3.htm)

On the other hand, building software is often done at a much lower level than building something physical and tangible. Working with assembly language would be like working with individual molecules. Working in something like .Net is better, but still somewhat lower level than bridge building. This is done for flexibility as others have stated, but the ambiguity of having several different ways to do the same thing, poor guidance from Microsoft, and building blocks that don't work in the expected ways leads to poor results.

When trying to explain to my wife what I do at my job, I told her "one third is trying to find out what people "really" want to do, one third is getting the technology to do what it's supposed to do, and the other third is watching it to make sure it keeps doing what it's supposed to do"

Something else to consider... which is a condition that's been growing over time, is with the ubiquity of the internet, the mentality of the modern programmer is "get something out there and fix it later". Decades ago when software was updated less frequently companies went to great lengths to ensure it was right first.

xnfec (5/15/2014)I think the key to this is insurance. If you buy agricultural products, it is possible to insure the quality and there are specialist companies that do this (SGS, Cotecna). They inspect the shipment and pass it as being of a certain quality. Then when it arrives, if it falls below that quality they pay out. Something similar could work for software. The insurer would come in, check the software and certify it then if it failed, they would pay out. The premiums could be substantial, depending on the software, but it would give organisations some peace of mind.

Koen Verbeeck (5/15/2014)I was stating two view points: on one hand, it is pretty impossible to get complex software - such as SQL Server - completely bug free. On the other hand, vendors have too much power in the sense that they can just shrug it off as "it's just a bug and we'll patch it someday. If you don't like it, just buy something else."

I agree - there are two viewpoints, but imho mandatory industry standards aren't going to help.

Perhaps there's a case for an organisation that certifies products or vendors to a given standard (if there isn't one already?). If it is demonstrably independent of vendors, buyers will have confidence that the products they buy are up to that standard. Vendors will be able to justify higher prices as a result of certification, so they benefit. For vendors that can't, or don't wish to meet the standard don't have to, and prices will necessarily be lower. Buyers then have a choice, and buyers with limited funds and flexible standards are free to use them.

I do agree with you. Mandatory would be too slow. Perhaps some basic bar or level of quality? Not sure, but there's something here.

However the other problem is buyers don't have the same rights. Somehow we've gotten to the point we don't allow "returns" if the software doesn't work. We don't allow resales if we don't like it and our friend wants it. We haven't built an industry that seems fair.

Koen Verbeeck (5/15/2014)Not only buggy software. Suppose the software works flawlessly. But it has to choose between two objects to impact when it is going to crash: you in a regular vehicle or the guy on the bike. To minimize damage, it chooses you.

Excellent point. Either way, somebody is going to get hurt. Some decisions should not be left to software designers, let alone coders. And it's probably still a fact that actual coders are lowest on the totem pole (is that P/C these days?). This illustrates why coding should not be left to peons.

And I'm different. I want a self-driving car. However I want those rules, and lots of that code, published. I want it open and reviewed, and I want there to be some consensus on how those decisions are handled.

Developers shouldn't make the decisions here, but we as groups, should be able to make some of those.

To be fair, how do you handle those decisions now? You haven't thought of most of them and you'd react. Perhaps badly.

Koen Verbeeck (5/15/2014)Not only buggy software. Suppose the software works flawlessly. But it has to choose between two objects to impact when it is going to crash: you in a regular vehicle or the guy on the bike. To minimize damage, it chooses you.

Excellent point. Either way, somebody is going to get hurt. Some decisions should not be left to software designers, let alone coders. And it's probably still a fact that actual coders are lowest on the totem pole (is that P/C these days?). This illustrates why coding should not be left to peons.

And I'm different. I want a self-driving car. However I want those rules, and lots of that code, published. I want it open and reviewed, and I want there to be some consensus on how those decisions are handled.

Developers shouldn't make the decisions here, but we as groups, should be able to make some of those.

To be fair, how do you handle those decisions now? You haven't thought of most of them and you'd react. Perhaps badly.