Managing fireworks complexity

In Seattle, home of Bill Gates, the New Year's fireworks display
stopped dead in its tracks twice. The pyrotechnicians had to reboot
both times.

We are hitting a complexity brick wall that banging into a statistical
problem.

If your probability of a line of code working without random coding
errors in p (hopefully a number just a minute amount less than 1),
then the probability of an n line program having no random coding
errors is p^n.  

As n increases your odds of a bug-free program become hopeless.

Even back in the 1980s I asked IBM for a list of the outstanding bugs
in their OS as part of a tender.  They went to my supervisor saying I
was unfairly harrassing them.  They pointed out that it would take
wheelbarrow loads of paper.

For every increase is complexity need to do two things:

1. increase the rigour of your testing and proving.

2. find ever higher level ways of expressing the application logic to
make the program more terse.  This necessitates hiding more and more
detail, and makes programs more and more consistent.

Programmers strenuously resist both measures.  

1. Testing/proving is boring.  Real programmer write code.

2. Programmers like to have very fine control of how the application
works, even if it means a cluttered mess like a teenager's bedroom. 
We need to start thinking of programming the way we think of HTML.
We need bare bones applications for the logic and style sheets to
GENERICALLY control the UI.
-- 
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com