Taken from the current (2 January 2016) edition of the UK's "New Scientist" magazine, without further comment.

Reliable software has its price
From Tony Green

Timothy Revell reports on efforts to develop software that can tolerate bugs (5 December, p 40). A major cause of buggy software is the attitude of some programmers and, rather more significantly, their managers.

In the 1980s, I was a utility programmer, producing software to automate much of our team’s work. Before allowing it to go live, I would always hand my code over to Pete. Pete had the most amazing talent for doing what no programmer would ever imagine anybody would do with a program; once my software was Pete-proof I could be confident it was going to work well.

By contrast, in the 1990s my job was to test a business-critical, complex and very unstable suite of code. Whenever I flagged up serious bugs that should have been showstoppers, I came under pressure to sign the release off so it could go live on its target date.

I made myself very unpopular by refusing to comply – especially among senior managers, who no doubt had bonuses riding on the schedule. I was shuffled off to another role so someone more compliant could take over.

I totally agree Richard.

But the key might be the definition of the word reliable.
As soon i or "the" programmer sees it as reliable this still applies.

---

With each crime and every kindness we birth our future.

I totally agree Richard.

But the key might be the definition of the word reliable.
As soon i or "the" programmer sees it as reliable this still applies.

I was thinking of you as our resident 'Pete' :-D

... And Boinc Devs and DA as M$ executives?

"You might think that, I couldn't possibly comment."

Code used to work because the company's reputation was its code. Today bugs are so common having a few isn't the end of the company.

---

Sounds WAY too familiar and not all that surprising.

I have worked in the "Information Technology" field in various roles/capacities for 30+ years now, at firms as small as 6 people to several of the "Fortune 500's" and these type things never seem to change.

Browse through the "Shark Tank" archives at http://www.computerworld.com/blog/shark-tank/ and you can find plenty examples that are similar to what you posted.

---

My profession for the past 17 years as been as a Software Test Engineer. I have found that the basic mentality of the S&M departments is that it is cheaper/easier to fix bugs after a product ships. Despite that mentality being proven wrong on many occasions.
In one instance leading to the company I worked for being sued into no longer existing & a more recent company having their reputation tarnished to the point they changed the name of their flagship product.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

In the late 1980s I was a developer for a small mainframe software company. I was asked if I could design and produce a prototype for a new feature for our primary product in time for a user conference that was a couple weeks away. I did. It was a bare-bones prototype framework that could be carefully demonstrated visually, but didn't yet have any real processing code to back it up.

The new feature was demo'd in the morning and then discussed in one of the conference's breakout sessions that afternoon. We had seven of our then-current users at the conference who really, really wanted the feature. One of them loved the prototype exactly as presented, while the other six suggested various additional enhancements that would be needed to make it truly useful for them.

So, I spent the next day or so back at the office trying to determine what it would take to accommodate those suggestions, finally determining that I could really only implement changes that would satisfy 5 of the 6. Not bad, I figured.

The following week I presented my findings to my boss and the CEO, who really only had one question....how long would it take to just turn the prototype "as presented" into an actual functioning feature, versus how long to also add the additional enhancements. My estimate was 4 weeks to make the prototype functional as I originally designed it, thereby satisfying 1 of 7 users, or 6 weeks if the additional enhancements were included that would satisfy 6 out of 7 users.

I suppose you can guess the response. Finish the prototype and ship it. Why? Because the prototype's design was sufficient to satisfy all the buzzwords that the salesmen needed to tout the new feature. The additional enhancements wouldn't add any additional buzzwords, even though they would actually satisfy better than 80% of our customers, rather than less than 15%. Besides, the extra 2 weeks might delay the next update release of the product (which, of course, ended up being 2 months late, anyway, due to other issues, mostly related to micro-management from the top).

I think I was gone from that company within a year.

---

I've written software for 40+ years and worked all sides of the problem.

I believe the outcome just comes down to risk, i.e. probability of the issue happening * consequence. When human lives or loss of huge sums of money are the consequence, even when the chance of failure happening is small, attitudes do change. For example a nuclear power plant meltdown or accidental detonation of a nuclear weapon behaviors do change.

If the consequence is small, you're going to get the put-it-out-the-door attitude.

Consequence to whom, assessed by whom?

Two of the most evil terms ever uttered in software engineering:

"First to Market"
"Agile Development"

About halfway through my M.S. in Software Engineering, I almost quit because it became apparent that the end-points we were being taught to work toward were how to create a marketable product and how to justify billing the customer. I graduated only because I was on a full scholarship, so... why not, right?

I do not work in the field and I never will.

BTW, one word I never heard (or read) during my coursework: "documentation".

[sad face]

---