May 15, 2014 at 9:46 am
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.
May 15, 2014 at 9:51 am
Why don't we build most of our software like we build bridges?
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.
May 15, 2014 at 10:06 am
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"
May 15, 2014 at 10:14 am
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.
May 15, 2014 at 10:38 am
Great line:
"The only reason coders' computers work better than non-coders' computers is coders know computers are schizophrenic little children with auto-immune diseases and we don't beat them when they're bad."
The more you are prepared, the less you need it.
May 15, 2014 at 10:54 am
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.
I wish insurance could help in some way.
May 15, 2014 at 10:58 am
david.wright-948385 (5/15/2014)
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.
May 15, 2014 at 11:01 am
skeleton567 (5/15/2014)
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.
May 15, 2014 at 11:02 am
Ralph Hightower (5/15/2014)
Try programming in APL. That is one bizarre language!
I liked APL, in a narrow domain of problems.
May 15, 2014 at 12:28 pm
Steve Jones - SSC Editor (5/15/2014)
skeleton567 (5/15/2014)
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.
I'd run over the biker. Less damage to me! 😀
(that was a joke)
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
May 15, 2014 at 9:08 pm
Breakthrough ideas, when responding to complex business issues, cannot and should not be confined to "best practices" and not even to "good practices". Those belong to simple and complicated business issues respectively, and I am sure that in those cases all do follow them.
When dealing with complex business issues, where innovative and creative solutions are required, a solution would require developing "emergent practices". This is one reason for the evolution of new concepts that has led to very impressive approaches that, over time, become "good practices" and even "best practices" for others as a complex issue becomes a complicated or even a simple issue.
With the advancements in the IT world, new technologies helping to reduce or eliminate existing business limitations, new approaches to business issues are possible and must be conceived and created. To have a regulated approach to creativeness is not possible in a complex and even chaotic world. The way we have successfully accommodated a limitation cannot be enforced once that limitation has been removed.
May 16, 2014 at 7:53 am
I'm not sure I've ever heard buggy code, bad design, and lack of security standards or QA referred to as an 'emergent practice' or 'breakthrough idea' before.
Kind of makes the old "its not a bug its an undocumented feature" joke seem mild.
May 16, 2014 at 8:16 am
Nevyn (5/16/2014)
I'm not sure I've ever heard buggy code, bad design, and lack of security standards or QA referred to as an 'emergent practice' or 'breakthrough idea' before.
^^like^^:hehe:
May 16, 2014 at 9:50 am
I don't think AmandS was suggesting buggy code, bad design, etc. should become viewed as emergent practice. Just that new programming methods and features become available before standards can be updated to reflect them.
May 19, 2014 at 11:24 am
skeleton567 (5/15/2014)
Ralph Hightower (5/15/2014)
Try programming in APL. That is one bizarre language!I'm not sure without researching it if APL and what we called in the old days Assembler Language are the same thing, but I've "been there, done that". It was a very efficient, fast, compact, precise tool and we always used it for the most exacting critical tasks. You had to be a real 'programmer' to use it, and we didn't have the naive folks 'managing' development. Real, experienced Systems Analysts were in charge and we got things right in development. Bugs in software were taken seriously and all identified were fixed without waiting for a 'next release'. Then along came the likes of COBOL which made so-called 'programmers' of those who weren't and shouldn't have been.
The industry really couldn't afford to code everything in assembler, there actually is a benefit to higher level languages, and COBOL at the time really brought benefits over assembler and to most folks in the industry it was a real no brainer. The resulting increase of the worlds programmer population was inevitably going to bring in folks who weren't up to your standards, but its worth considering how far we would have got if we stuck with assembler for everything, I'd hazard a guess not very far 😉
Viewing 15 posts - 31 through 45 (of 45 total)
You must be logged in to reply to this topic. Login to reply