status of Programming by Contract (PEP 316)?

[Steve Holden]

Chris Mellon wrote:
> On 8/29/07, Russ <uymqlp502 at sneakemail.com> wrote:
[...]
>> If you are
>> programming something that doesn't really need to be correct, than you
>> probably don't need it. But if you really need (or want) your software
>> to be correct and reliable as possible, I think you you should be
>> interested in it. You might want to read this:
>>
> 
> You don't want your software to KILL BABIES, do you? If you don't want
> your programs to KILL BABIES then you should use our technique, so you
> don't KILL BABIES.
> 
> There are ways to make correct programs besides DBC. It may not even
> help in the general case - just as with unit testing and type proving,
> you're going to be limited by what you don't think to assert or
> document or test, and I've seen no evidence that DBC is any better
> than anything else at preventing unwritten assumptions.

Personally I have found the best strategy to be KWYD: know what you're 
doing. Your assertion that success of DBC relies on the competence of 
the practitioner is indeed true, just as it is for all other 
methodologies. The number of programmers who *don't* know what they are 
doing and yet manage to find well-paid employment in mission-critical 
system implementation is truly staggering.

If I can blow my own trumpet briefly, two customers (each using over 25 
kLOC I have delivered over the years) ran for two years while I was away 
in the UK without having to make a single support call. One of the 
systems was actually locked in a cupboard all that time (though I have 
since advised that client to at least apply OS patches to bring it up to 
date).

This was achieved by defensive programming, understanding the user 
requirements and just generally knowing what I was doing. Nevertheless I 
would hesitate to write code for such demanding areas as real-time 
rocket flight control, because I just don't think I'm that good. Very 
few people are, and learning as you go can be disastrously expensive 
when military and space projects are involved.

But it's always a good idea to make your software "correct and as 
reliable as possible", isn't it? The problem is the external constraints 
on the project. As the old saying goes: "Cheap, fast, reliable: choose 
any two".

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------