This is a microcosm of how crap code gets into production. It is not conceived and developed against sustainable models, grows like Topsy and it's "suckiness" is discovered too late for a major rewrite. There simply isn't the money in the pot even if you are a large corporation. There are several large corporations in the same position as your unnamed word processor vendor. For example a well known purveyor of document reader software has a committed team that would just love to rewrite the product but is unable to assemble the funds. Right now they are flat out staving off attacks from Russians who have found vulnerabilities that allow them to crash and invade PCs running the software at a high level of security.
Perhaps by now the uninitiated may appreciate how irrelevant a collegiate debate on the ambiguity of a standard is to situations such as these. I wonder if any standards bodies ever do a 360 review on what the profession thinks of their standards and how they are used, or if they are used at all. I recently had the opportunity to review the curriculum of the University of Queensland's Electrical Engineering and Computer Science Department. The curriculum guy had never heard the number 61508. In Bristol last year I attempted to get a sneak peek of ISO standards work and asked PBL about the process of signing up as an industry reviewer. He regarded me with horror. I stood by for the gush of boiling oil from the top of his silo.
It saddens me that humanity takes so long to learn. Shakespeare knew about the ramifications of piling bad on bad in 1605 when he had Macbeth say:
Light thickens, and the crow
Makes wing to th' rooky wood.
Good things of day begin to droop and drowse;
Whiles night's black agents to their preys do rouse.
Thou marvel'st at my words: but hold thee still.
THINGS BAD BEGUN MAKE STRONG THEMSELVES BY ILL.
Cheers
Les
PS:
By the way I'm not against Fagan reviews, they can be good value when used
as designed. I wrote an essay on my first exposure to them here:
http://www.systemsengineeringblog.com/extreme-review-a-tale-of-nakedness-als
atians-and-fagan-inspection/
... but they are designed for inspection of completed deliverables, they are the end game not the arc of the story.
-----Original Message-----
From: systemsafety
[mailto:systemsafety-bounces_at_xxxxxx
Steve Tockey
Sent: Wednesday, March 2, 2016 5:07 AM
To: Derek M Jones; systemsafety_at_xxxxxx
Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous
Graphical Representation"
Derek,
An interesting position, but please consider this alternative view:
I'm using a popular word processor for writing my new book. I've seen reports from credible people who have evaluated that code base, they all report, "it sucks". I know people who work for that company, they freely admit "our code sucks". No question, it's bad code.
As a user, I have already logged 93 unique defects against the product. The most serious defect is that it can go into an infinite loop after a Paste. When it does, I have to go to the operating system control panel to kill the process as it is consuming 100% of one CPU and not listening to any user input. My habit now is to Save-Cut-Paste instead of the normal Cut-Paste to minimize lost work (it's supposed "saved" version is up to 20 minutes of editing behind). Web searching reveals that this infinite-loop-on-Paste defect has been in the product since 2011 and has still not been fixed. I can't think of any other way to put it, it's bad code.
But here's the deal, I can't invest anything in that code. It's not my code to invest in. I'm just the poor hapless user who has to deal with their crap because that's what the publisher wants.
Your position is fine from a supplier-side perspective, but what about the consumer-side? Shouldn't we have a say? At best, all I can do economically is be true to my vow of never spending another penny with that vendor. They've gotten enough of my money over the years for their schlock software. No more.
It's not my option to invest in their code. All I can do is make it obvious that I refuse to spend any more with those schmucks.
Regards,
-----Original Message-----
From: systemsafety <systemsafety-bounces_at_xxxxxx
on behalf of Derek M Jones <derek_at_xxxxxx
Organization: Knowledge Software, Ltd
Date: Tuesday, March 1, 2016 8:13 AM
To: "systemsafety_at_xxxxxx
<systemsafety_at_xxxxxx
Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous
Graphical Representation"
Steve,
> My point is that it's not a simple thing to precisely define "bad code",
> neither is it a simple thing to detect it or repair it.
Bad code can be precisely defined by the amount of resources you are willing to invest in finding and fixing any problems it might contain.
If the code might contain problems that you are not willing to invest in doing anything about, then it is obviously good enough.
How you choose to invest the resources you have in finding/fixing problems is a technical issue. There is not a lot of hard data available to help make the optimal use of resources, so people tend to follow the herd and sprinkle in a few of their own preferences.
-- Derek M. Jones Software analysis tel: +44 (0)1252 520667 blog:shape-of-code.coding-guidelines.com _______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx _______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx _______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxxReceived on Wed Mar 02 2016 - 00:44:21 CET
This archive was generated by hypermail 2.3.0 : Fri Feb 22 2019 - 05:17:08 CET