[plt-scheme] contracts.ss: Can you disable them at runtime?

From: Geoffrey S. Knauth (geoff at knauth.org)
Date: Fri May 18 01:47:15 EDT 2007

On May 17, 2007, at 22:12, Shriram Krishnamurthi wrote:
>> > And what if they don't?  How about for other people?
>> Then they should leave them on.
> Really?  Even when their contracts and/or their tests change the
> O(.) complexity of their programs?

I knew about contracts from Eiffel, but in my late-1990s non-Eiffel  
big project, I used logs:

I wrote a fairly complex military logistics system for US DoD.  It  
took a couple of years, but they liked it, it saved money, the system  
ended up winning awards, etc.

The system I wrote at BBN had quite a bit of logging, because I  
didn't trust myself, particularly at those moments when folks asked  
me to add new functionality very quickly.  The logs helped me watch  
the decisions the computer was making, and I made the logs friendly  
to humans so that logistics experts who were not technologists could  
understand the logs too.  They really, really liked the logs.  The  
logs gave them confidence and auditability when things were going  
well, and gave them clear insight into problems when things went  
wrong from time to time.  Happily, the logs did not impact  
performance noticeably.  They would have never dreamed of asking me  
to turn off the logs, because at the moment the system became a black  
box they would have stopped trusting it--they certainly knew I was  
fallible.  I remember that period fondly--we had passionate  
developers and passionate users working hand-in-hand.

Later the system was completely rewritten by another company in Java  
to comply with an all-Java directive, most likely to wrest control of  
future development away from pesky developers (Java developers are a  
dime a dozen and easily replaced) and away from domain experts (who  
loved to dream up new functionality), and into the hands of tiers of  
managers devoted to one master, Microsoft Project.  I became an  
advisor to the Java transition.

What I remember about the transition was that the logs were not a  
part of the new system, and the performance of the new system was  
much worse initially, so the end users were newly unhappy:  they  
waited forever for answers, and couldn't see how those answers were  
computed.  Eventually the performance problems were mitigated, partly  
through the addition of powerful hardware, partly through complex  
caching of enormous intermediate query results, and eventually an  
independent query facility was backfitted to the design to offer some  
measure of cross-check.

The new, glorified data processing system eventually worked, that is,  
it computed correct answers, but never as fast as the old system, and  
what I missed most was the old system's ability to record its  
thoughts for humans to examine.

Posted on the users mailing list.