Steve Holden wrote: [...] > 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. On the one hand, nice work. Made your customers happy and kept them happy. Can't argue with success. On the other hand, 25K lines is tiny by software engineering standards. If a support call would have to go to you, then the project must be small. Software engineering is only a little about an engineer knowing or not knowing what he or she is doing; the bigger problem is that hundreds or thousand of engineers cannot possibly all know what all the others are doing. I work on large and complex systems. If I screw up -- O.K., face facts: *when* I screw up -- the chance of the issue being assigned to me is small. Other engineers will own the problems I cause, while I work on defects in code I've never touched. I wish I could own all my own bugs, but that's not how large and complex systems work. Root-cause analysis is the hard part. By the time we know what went wrong, 99.99% of the work is done. Design-by-contract (or programming-by-contract) shines in large and complex projects, though it is not a radical new idea in software engineering. We pretty much generally agree that we want strong interfaces to encapsulate implementation complexity. That's what design-by-contract is really about. There is no strong case for adding new features to Python specifically for design-by-contract. The language is flexible enough to support optionally-executed pre-condition and post-condition checks, without any extension. The good and bad features of Python for realizing reliable abstraction are set and unlikely to change. Python's consistency and flexibility are laudable, while duck-typing is a convenience that will always make it less reliable than more type-strict languages. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
