Schedule and Events



March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email: Matt.Heusser@gmail.com

Wednesday, December 20, 2006

Test or Hardware Architecture ? - I

In the 1960's, we had the "Software Engineering Crisis", which was essentially the problem that NATO could not develop software supply to meet demand. The solution, more-or-less, seemed to be TQM (at least, according to NATO), which had it's pros and cons. (I think Tom DeMarco offered a more credible, economic explanation in "Why Does Software Cost So Much", but I digress.)

A more recent crisis, and, in my mind, a more credible one, is the software testing crisis that Dr. Cem Kaner has been suggesting. Basically, that twenty years ago a "big" program was about 10K lines of code and written in COBOL - even a manager could understand it. A good tester could put the whole program in his brain and evaluate behavior. Today, a big program is four millions lines of code and written in a higher-level language like Java. While programmers have had orders-of-magnitude improvements in that time (think COBOL to C to C++ to Java to Perl, spagetti to structured to OO), in many cases testers are using the same techniques they were using in 1986. The result? Testing as a profession is in danger of losing it's relevance.

Interestingly enough, the world of computer architecture is going through the same thing. No, not enterprise architecture (whatever that is), but real architecture - bits and registers and adders and instruction sets. For the past thirty years, Moore’s law has promised faster chips every twelve to eighteen months, and it's slowing down.

I'm sure you've heard the Intel ads for "dual core", and that is the current big bet of hardware architects - massive parallelism. The problem is that not every problem can benefit from being split into component parts and re-assembled. Sure, computing PI or calculating the area under a curve might, but what about word processing? And even if we could speed up word processing, it's doubtful that the compiler will be able to make the program faster - a human being is going to have to program for it, which means you'll have to teach the programmers how to make parallel programs.

There is an interesting interview this month in ACM Queue that explores these issues:

http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=445

I think that what the chip designers are proposing can be done, and done much easier, for software testing: Teach developers how to test. More about that later ...

No comments: