Ten years between posts, eh?  That has to be some kind of a record. I just read a book review that reminded me I've never read much Irish literature, that some of it is very good, and there is always more to learn.  Flann O’Brien (as Myles na Gopaleen): The Best of Myles. Harper Perennial, 2007. 400pp
ISBN13: 9780007247189

Lyons and Tibers and beers

I am assuming there are *no* readers of this blog, other than myself. Not that, if I write something inflammatory or denigratory, enough, this post doesn't have to be read any time soon to be a personal embarassment or professional curtailer at some point.

Everything old is new again

Just finished helping to write the first draft of a software developer certification study guide. It's intended audience is recent CS graduates and lightly-experienced (< 3 years) developers. The modules cover requirements, design, construction and testing. The difficulty with the writing was pulling information that is so second-nature up into my consciousness -- I mean, who needs to be told that using ASSERTs is a good programming practice? It felt like I was writing down the blindingly obvious, but my experiences in software design and development over the years, across many organizations reminds me that most developers don't know, or at least don't use, the blindingly obvious.

One of the content areas was about re-use. What can you say about re-use? "Re-use is good, do it a lot." The benefits are staggeringly clear, who needs them explained? My second paying job was programmer at a bank. The computer was an IBM 360/40 with 128K of main memory, we wrote everything in assembler and during the day ran a 64K foreground partition and two 32K background partitions for assembly and test. The disk system was flat files (no relational d/b technology yet). There was a flat file containing all the savings accounts sorted by account number, new accounts were added to a second 'new accounts file' that was appended to the main file every night and the main file re-sorted. (3rd shift operator at that bank was my first paying job).

Savings transactions were written to a second file. The main file had a pointer at the end of each savings account record that pointed to this Savings Overflow File, and each of the records in the SOF had a pointer to the next transaction for that account in the SOF. I got an assignment to write a program doing something (can't remember what) with savings accounts and I had to write a routine to find the account record in the main file and run the chain of transactions in the SOF. It occurred to me that this must be a common problem and I researched IBM's OS manuals and found that OS/360 offered a library function, where a pre-compiled binary could be stored and called from any program. I wrote my search routine in a form that could be stored in the library, called it from my program, and sent out a memo that from now on, no one needed to write a savings overflow trailer search, they could just call my routine and save a day or two of programming & debugging.

No one else in the shop used it. Ever.

A perfect example of re-use. Why wouldn't the other programmers use a tool that made their lives easier, that would make them more productive (looks good to the boss), that would eliminate complexity from their programs, and especially! reduce debugging effort? I was baffled and remain so to this day. For most of the programmers I've seen, re-use ends at copying some code that does something they need to do and pasting it into their own program. Why ignore such an obviously beneficial technique?

So the study guides were hard to write.

I have a reader!

Not counting bots and spammers, that is. Welcome Gary, and this one's for you.

Regression testing is not a phase

Time to vent. Probably past time.

One of my several careers has been as a software tester. I enjoyed it more than programming, probably due to the destructive side of my nature. I learned a few things and tried to share them with other developers and testers, but most have been disinterested in (or unable to) change. I finally figured out why.

I was reviewing some test plans at a client's site and came across some language that I had seen before at other companies and for other systems. Roughly, it goes "first we'll have the developers do unit testing, then we'll do the system, regression and integration testing."

The problem with that sentence is that regression testing isn't a phase -- it's a technique.

Regression testing is the re-running of tests from earlier releases to see if the changes made for the new release have damaged ("regressed") the software's existing features. There is no such thing as "regression testing", but there is regression unit testing, regression feature testing, there should be (but rarely is) regression user acceptance testing.

The tests written to exercise the new features are new tests, not regression tests. They're added to the regression test suite when the release is promoted to production and will be re-run for the next release.

Regression testing, when done properly, uses the same input data every time

Another testing technique that is rarely used but should be required is challenge testing.

Challenge testing is feeding the system bad orders, entering too many characters into the zip code field, logging on with the wrong password. Challenge testing is assaulting the system in an attempt to find things that don't work right.
Unfortunately, the users don't want to find things wrong with the system, they want to prove tht it works. That's not possible with 'happy path' testing alone and, in fact, isn't possible at

Sun Tzu

I like to re-read books. There's always something new to find -- not in the book, but in yourself, of the circumstances the book lies against today instead of yesterday or tomorrow. Came across this today:

1. Sun Tzu said: In the operations of war,
where there are in the field a thousand swift chariots,
as many heavy chariots, and a hundred thousand
mail-clad soldiers, with provisions enough to carry them
a thousand li, the expenditure at home and at the front,
including entertainment of guests, small items such as
glue and paint, and sums spent on chariots and armor,
will reach the total of a thousand ounces of silver per day.
Such is the cost of raising an army of 100,000 men.

2. When you engage in actual fighting, if victory
is long in coming, then men's weapons will grow dull and
their ardor will be damped. If you lay siege to a town,
you will exhaust your strength.

3. Again, if the campaign is protracted, the resources
of the State will not be equal to the strain.

4. Now, when your weapons are dulled, your ardor damped,
your strength exhausted and your treasure spent,
other chieftains will spring up to take advantage
of your extremity. Then no man, however wise,
will be able to avert the consequences that must ensue.

5. Thus, though we have heard of stupid haste in war,
cleverness has never been seen associated with long delays.

6. There is no instance of a country having benefited
from prolonged warfare.

Inherited Ideas

Inherited Ideas
Nothing new to report? Sadly, no. Lots, in fact. Today I'm still home with the flu, but at least I get to do this....

Friday afternoon