Lone Coder: The Cost Risks of Programming Standards

Ken Burtch ken-8VyUGRzHQ8IsA/PxXw9srA at public.gmane.org
Wed May 6 14:22:09 UTC 2009


Fair enough.  Can we agree that some efforts to deploy programming 
standards lack an understanding of the purpose for which the standards are 
being deployed, turning them into an ego or power exercise?  Although 
risks cannot be perfectly assessed, surely some common sense questions 
like "is what we're enforcing really addressing the issues" are valuable.

Ken B.

-----------------------------------------------------------------------------
Ken O. Burtch                                       Phone/Fax: 905-562-0848
   "Linux Shell Scripting with Bash"                  Email: ken-8VyUGRzHQ8IsA/PxXw9srA at public.gmane.org
   "Perl Phrasebook"                 Blog: http://www.pegasoft.ca/coder.html
-----------------------------------------------------------------------------

On Mon, 4 May 2009, Christopher Browne wrote:

> On 2009-05-02, Ken Burtch <ken-8VyUGRzHQ8IsA/PxXw9srA at public.gmane.org> wrote:
>> My latest essay.
>>
>> Ken B.
>>
>> "...Risk assessment defines risk and cost times probability. If a fire
>> will
>> cause $1000 in damage and will occur every 500 days, then the risk
>> represented by the fire is $2 per day. A person should budget no more
>> than $530 a year to prevent such a fire because any more would mean
>> spending more money than it would cost to clean up after the fire. Of
>> course, this kind of assessment requires an accurate assessment of the
>> risk and the cost..."
>
> The trouble is that "accurately" assessing the risks and the costs is rife with
> both trouble and further cost, because this simplifies things several
> crucial ways:
>
> 1.  The expectations aren't based on one event and one probability, but is
> instead based on many possible events with varying likelihoods.
>
> 2.  Determining the list of possible events is troublesome.  When thinking
> of "possible disasters," being struck by lightning or by a meteor or by a
> surprise satellite that falls from orbit are things that could happen to a
> building.
>
> I expect that it's usually worth leaving "struck by an asteroid" off the list,
> but it is by no means obvious where the "tail end" of the curve lies.
>
> 3.  Given the set of events, the probabilities and costs may be difficult to
> estimate, and they may suffer from the ability to change.  Crime levels
> change over time (these days, I'd be un-keen on visiting Mexico City on
> business, as it sounds like the kidnapping rate has gone up, and we've
> all heard about the piracy problems near Somalia).
>
> Applying this to code:
>
> "If Ada became the hot, in-language  you would see a lot more bad code
> in   Ada."
> -- Thaddeus L.  Olczyk <olczyk-IKAnbrrkwKZdz2imjWt+ww at public.gmane.org>, comp.lang.C++
>
> 4.  Unless the previous sets of work have been done properly, the numbers
> mayn't be of any help in guiding actions.
>
> Some pretty intense public policies have been generated over the last number
> years falling out of events as diverse as:
> - 9/11
> - Somalian piracy
> - Swine flu
> - Shootings at schools
> and in virtually all cases, knee-jerk reactions have been generating
> *BAD* policy
> because these have similar properties to lotteries where, since:
> a) The probability of an individual event is so low, but
> b) The consequence of an individual event is so high, and
> c) Consequences of the events are sufficiently heinous as to be
> public-news-worthy
> and this adds up to people not actually being capable of being rational
> about them.
>
> There aren't enough actuaries out there to *properly* assess the various
> risks that people are worrying about, and they all work for insurance
> companies anyways, and therefore don't get drawn into these sorts of
> analysis very much.
> -- 
> http://linuxfinances.info/info/linuxdistributions.html
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
>
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list