On a daily basis I am forced to deal with software that does not function properly. Is it just not cost effective to test it throughly? Web sites with light gray print on a white background are near impossible for me to read. I guess accessibility issues do not apply.

It seems that the banks software and Amazon's software work pretty well. Spending several hours trying to get something to work properly is not my idea of fun, particularly when doing it on paper takes about three minutes.

That's what you get when you outsource software development to the lowest bidder in some third world shit hole, or hire a "consulting" company that uses imported "talent" via H1B visas.

Proper testing, proper QA methods, are historical concepts.

The dumb shits that did our software where I work designed the software on a nonrescaleable platform. They have real computers and we use tablets.

There are as many as five scroll bars on the screen at any given time.

At one point in my career I worked for a company that outsourced their nuclear-material handling software overseas.

Bugs in the final software rollout were everywhere. In some of the menus if you had a prompt where the query was "Is this correct?" and your choices were "Y" or "N"... if you hit any other button by accident the software would lock up or crash.

What was most amazing was that it took some four months to get the bugs fixed. Should never made it past off-line testing.
(And this software managed nuclear material criticality concerns- but hey, it was cheaper than having US programmers do it!)...

This is not a new complaint. The first Mrs. cne32507 was confronted with crappy new integrated industrial software at her work. This was on an IBM system in the pre-PC era decades ago. The good thing that came out of it was she had to travel to Portland, Maine to train their personnel. We made it into a nice vacation.

quote:

Originally posted by ZSMICHAEL:
On a daily basis I am forced to deal with software that does not function properly. Is it just not cost effective to test it throughly?

No. It's more a question of most software people aren't particularly competent.

Between software design and I.T., I was in the business for 35+ years. In that time I saw far more poor software than good.

A few tales from the trenches...

At one employer we had a female software engineer who management just loved. Just loved her to pieces. Mainly because she talked a good game and would crank out software quickly. (I always suspected also because she was perky and kinda cute.) Problem was: The code she wrote was utter crap. I mean some of the most abysmally lousy code I ever had the misfortune to encounter either before or after her.

On a consulting gig I had to straighten-out some industrial control ladder logic that was so bad I couldn't make sense of why it ever worked at all. When I asked "Where the hell did they find this guy?" I found his degree was in music and he'd never written a line of software, in any language, before the vendor who'd employed him had hired him. (In the end it turned out to be easier to rip what he'd done out completely and re-code it from scratch. It had been that bad.)

Or how about the industrial controls "engineer" that had designed a piece of automation that required an operator load the part, then a very dangerous stabby thing would plunge down so the machine could do its thing. I looked at the machine and asked him "Where's the hand stand?" (A "hand stand," in industrial controls parlance, is a thing with a pair of palm buttons on it used to activate a control in such a manner that the operator's hands cannot possibly be in the machine when it's cycled.) He looked at me like "Huh?" There was no light curtain around the moving bits, either. (A "light curtain" ensures nobody sticks an appendage into a dangerous area while the machine's in operation.)

An executive at one employer of mine didn't care to trust my counsel and hired a contracting firm to design a customer portal. When it became clear they were going to completely disregard everything about which I tried to caution them, I informed my boss "Y'all are on your own. I ain't goin' near that thing." Eventually I was obliged to, anyway--after said contracting firm had finished the job, gotten paid, and was long gone. The code was riddled with bad coding practices, bugs and vulnerabilities, and had a back door with a password in plain text.

At one employer I was once called upon to sit in on a meeting between the highest-ranking execs at the company and some people from our bank, regarding a new mechanism they were going to use to handle... uh... certain financial operations. When I was informed of what we'd have to do to allow our desktops to work with their software, I waited until the PHBs were otherwise occupied, leaned over and quietly said to the bank's geek "You realize what you're asking us to do creates security vulnerabilities on our desktops, right?" "Yeah," she replied. "I've told them. They don't want to hear about it." That was a bank. And not a little mom-and-pop bank, either.

If I wanted to sit down over several evenings and think about it, I could probably come up with dozens-upon-dozens of such stories.

There has been a saying in the world of software design for as long as I recall that goes something like: "If buildings were built like software is designed, the first woodpecker to come along would destroy civilization."

The sad thing is we know how to do better. We've known for a long time. I have books on my bookshelves to prove it. We just don't.

 
Early on in the birth of the WWW, our programmers were designing basic web sites. They weren't really "programmers", just people being trained to develop web sites. One mistake made early, and painfully, was in placing a "Send this page to a friend" link on the web site. You would fill in your friend's email address and click send. Unfortunately, the "developers" did not check the input for that link, and the spammers soon discovered they could stuff 1,000 email addresses into the field and send the link and their spam message en masse.
 
This remains a big problem, not checking input.

Technology is fast paced and moving rapidly with improvements.
It used to be "don't fix if ain't broke" or "don't do anything in the first release" etc,, but now days it pays to push the technology for the better.
I always was on, pushed or recommended the leading edge and generally had fewer problems.
Except for those hanging on to legacy products or devices and or those who subscribe to the "don't fix if ain't broke" philosophy.
Same goes for website developers but it is not entirely the website's fault - many times it is the user.
Sooooo many are getting bogged down with all the AI/shopping data collection.
Good thing for increased bandwidth and better compression techniques along with faster hardware and software.
One pleasant exception is the SigForum that runs exceptionally trouble free albeit some features aren't there - I am perfectly happy with staying the same here.
I think the click-bait AI-data collection heavy sites are the ruining many sites just to get a little payday for clicks.

Dijkstra pointed out that it's much easier to teach the "mechanics" of mathematics than it is to teach mathematics. What we have is Off-Shore universities teaching the mechanics of programming in hopes that their pupils might learn to program. If you ask an H1B Java programmer what is a class-loader s/he will give you the "interview" answer. If you ask her/im for more details s/he is "very busy" right now. --- But they are cheap (as opposed to inexpensive!).

As long as management can be sold the latest "Silver Bullet" and hires people who can't "shoot worth s***" useless code will continue to be produced. Worse management will insist that this "investment" not be lost and demand that their "sow's ear" be turned into a purse.

According to Joel Spolsky, good software takes 10 years: https://www.joelonsoftware.com...ears-get-used-to-it/
That article was written 18 years ago, but is still relevant today.

I think many current gen SW developers don't have the discipline and rigor to properly design and ensure that functional requirements are captured comprehensively. I think analysis is gone as developers jump from high level requirements and arch to coding at the cost of function and exception handling.

I see all kinds of crap software these days.

I was browsing online for a new truck and majority of the dealerships have this chat box pop up. You know the one with some pretty looking models face and says we are online to answer any questions. Great, however this chat box is blocking the sort/filter button on the website and I cannot search for the truck I want.

Many years ago, my boss returned from an industry show, all excited about a new software package. He arranged for us (me) to use the demo version of it for 30 days, and let him know if we should buy it.

At the end of the demo period, the sales guy for the software company came in with my boss to ask my opinion. I told him how bad the software was, and gave them a list of 107 things I would like to see changed. They were both livid, and my boss threatened to fire me because of it. The sales guy took my list and disappeared in a huff.

A few months later the sales guy, his boss and their software guy stopped by to ask if I would try their newest version.

They had incorporated 105 of the 107 ideas I had given, into the new software.

I can't stand software, websites, etc., that are poorly-designed or don't work properly. For example, those new kiosks at your local McDonald's. Really bad.

quote:

Originally posted by ridgerat:
Many years ago, my boss returned from an industry show, all excited about a new software package. He arranged for us (me) to use the demo version of it for 30 days, and let him know if we should buy it.

At the end of the demo period, the sales guy for the software company came in with my boss to ask my opinion. I told him how bad the software was, and gave them a list of 107 things I would like to see changed. They were both livid, and my boss threatened to fire me because of it. The sales guy took my list and disappeared in a huff.

A few months later the sales guy, his boss and their software guy stopped by to ask if I would try their newest version.

They had incorporated 105 of the 107 ideas I had given, into the new software.

I can't stand software, websites, etc., that are poorly-designed or don't work properly. For example, those new kiosks at your local McDonald's. Really bad.

It's funny, as frustrating as those kiosks are they're enormously superior to trying to order from a human at a register. The degree of easy, ACCURATE customizability you get through the kiosk is astonishing compared to the old fashioned way.

Yes I have kids who like McDonalds but are picky eaters. We can only go to the places near us that have switched to kiosks, it's the only way their burgers ever arrive they way they like.

Anyway I've been doing IT work for around 20 years now, and even before I got into it for years I had friends in IT. Sturgeon's Law will not be denied, because people fuck everything up.

quote:

Originally posted by 4x5:
According to Joel Spolsky, good software takes 10 years: https://www.joelonsoftware.com...ears-get-used-to-it/
That article was written 18 years ago, but is still relevant today.

It's not just software, it's everything. It takes ten years or 10,000 hours of focused practice to become good at something. It's a concept that flies in the face of our "right now" culture.

...and the decisions that people make because of it....

A Seattle based coffee company has a policy of promoting from inside the company to keep the company's culture in place over time. You'll get some ditzy young woman.... with NO technical background,.... leading an entire IT department. I think everyone here knows the outcome of that.

Personally, I write "adaptive algorithms" as a hobby. I've gotten good at it over the past 15 years and I'm asked to consult on AI projects on occasion. What's interesting about the work is talking to the people who are interested in implementing these types of systems at the corporate level. Their goals are not as lofty as you may think.

What every employer wants, large or small, grand or humble, is for an employee who will follow directions. You just can't get people to do it. You can talk about reducing costs but this is what people seem to be asking for more than monetary gains.

It is something to consider.

V.