Let the Adventure Begin

I miss having an outlet for my writing. It’s time to plug in to that outlet again, and what has inspired me is my vacation, starting tomorrow. It’s the first time I can remember burning two weeks of vacation all at once – two weeks and a day.

Here’s the idea: drive from Texas to Washington state and back again. Six people and dog in a minivan. Accommodations will include a tent, several homes of family and friends, and the most interesting hotels we can find that will accommodate six people and a dog in one room.

It’s difficult to find hotels that will accommodate more than four people in a room. They’d be happy to take my money for two rooms, though it seems that most hotels no longer offer adjoining rooms. They won’t make any guarantees in advance that two rooms would even be near each other. I don’t really want to split the family apart, so I’m going to stick with one room. More details in a later post on how that came together.

It’s also a bit difficult to find hotels that accommodate dogs, especially large dogs. Now imagine finding room for six people and a dog, and I have a challenge on my hands. Add a one-way flight for a minor who’s coming home early, and we get one complex itinerary.

We’ve already looked at renting a tree house and a cave. Sorry, no pets. Some don’t even allow children. But we’re not giving up on keeping it interesting!

In fact, we’re debating now whether to also bring a pet chicken. I have a bad feeling about this. But I’m certain that one way or another, we’re going to have quite an adventure.

Unit Testing – A Taste of My Own Medicine

Tags

, ,

Throughout my career, I’ve been fussing at software developers about not doing decent unit testing. Recently I had to focus that fussing on myself.

I like the idea of test-driven development, where an automated unit test is developed in conjunction with the product code. But I don’t do it very often. Sometimes it’s because I don’t know if I’ll ever use the code I’m writing again – it’s just a one-off thing that won’t need to be repeated after the code does its work once. Sometimes it’s because of the difficulty in setting up a unit test, like my code that uses Watir to automate Internet Explorer. Some of my excuses are the same kind of excuses that the developers I’ve been fussing at have used.

I’m not ready to draw any big conclusions about unit testing, either for my test automation or for product development, but I do want to relate a success story. I had been struggling for a couple of days with a Perl program that parses an SCL script (OpenSTA’s scripting language). It would read in the SCL file, piece together all the line continuations so I could search each statement as a single entity, modify some of the statements, then split them back up into shorter lines. It was mostly working, but little glitches kept appearing – extra blank lines would appear, a line would be cut off too short, etc. As soon as I fixed one glitch, another would appear – the parsing process was fairly complex.

Finally it dawned on me that if a developer were to describe this problem to me, I would suggest that he immediately write unit tests. So that’s exactly what I did. I tried Perl’s Test::Unit module in earnest for the first time. It took a while to figure out how to set up the tests – the examples in the documentation are too trivial to show how a real unit test would work. But after a few hours, I was adding tests, and the tests were finding bugs. It only took a handful of rounds of adding a test, fixing a bug, then finding and fixing the bugs that the fix uncovered. The glitches were gone.

So while I struggle to find the right balance to determine what test automation code should have unit tests, I’ve learned that the code that isn’t working is definitely a good candidate for unit testing.

Originally published on the Tejas Software Consulting Newsletter blog.

Convex is dead, long live Convex

I don’t think I have a tendency to dwell on the past. Yet an employer that I thought I had parted company with years ago always seems to be popping up in my thoughts. The company is Convex Computer Corporation, the pioneer of “affordable supercomputing,” where I worked from 1992 to 1995. Convex as an institution is gone, but much to my amazement, its culture is very much alive. I’d like to pay a tribute both to the demise of the institution, and to the unique spirit that lives on.

Convex is dead

What happened to the institution? After outliving practically every other competitor in the market that they created, Convex ran out of money and sought a merger with Hewlett-Packard, which was completed officially in December 1995. Cultural changes were inevitable, but mercifully, most of the changes came slowly. The first big shock for me was when management removed all Convex paraphernalia and pictures from past events from the walls in the hallways. They laid them all out in the company meeting room and told us to take what we wanted, and served ice cream to “celebrate.”

I consider the next big milestone to be the end of the Friday parties, which happened after I left what was then Hewlett-Packard. Convex had a long-standing tradition of bringing beer kegs into the main breakroom on Friday afternoons, along with other drinks and snacks. I vividly remember the one time my wife attended. She stood there, shocked, and said something like “My God, they’re all geeks!” I did some of my most inspired test tool development after the Friday parties. I’m told that the last Friday party was Friday, the 13th of April, 2001, canceled for the sake of cost-cutting.

Then on September 23, 2002, I got a disturbing announcement stating that the entire software development lab I had worked for was shut down. There are still a few ex-Convex employees working for H-P at the old Convex site in Richardson, Texas, and definitely a number of Convex folks who have relocated to other H-P locations. But it’s hard to find much of the Convex legacy that’s left at H-P.

Long live Convex

Nowadays, Convex lives on in the people who were there. As I wrote this, I received an April Fool’s joke in an email on the “ex-convex” mailing list. April Fool’s jokes are a prominent component of the hacker culture, and the Convex culture has a lot in common with hacker culture.

I got a blast from the past when a political discussion recently broke out on the ex-convex list. It was a full-scale, flame-throwing, no holds barred debate. It was old friends, who saw no need to tread lightly. It was the same sort of discussion that used to take place on the internal Usenet newsgroups at Convex, and several people were amused to see that the group was still up to the task.

I didn’t realize how many Convex connections I’d maintained until I sat down to write about them. I recently sent congratulations to Ron, a former manager of mine, who decided to retire rather than try to find another job after the shutdown. I worked on a project with Prathibha and Hema, testers I had worked with at Convex and who landed contracting positions with one of my clients. Matthew, another ex-Con (the affectionate shorthand for an ex-Convex employee), is an employee on that same project. I spent a week at a training course last year with Daryl, who was my first team lead when I started at Convex. I worked on a writing project with ex-Cons Eric and Martin. I met Mark at a local networking event. I touched based with Orion and Darrell when passing through San Francisco last month. I met Prasad and his wife for a social visit when they came through town last December. I consulted with Peter about writing this article. That’s just a sampling.

I don’t try to seek out my former Convex employees any more than anyone else in my network. But they’re still a core part of my network more than three years after I left H-P, and seven years after Convex officially went kaput. Countless times, I’ve heard ex-Cons say that Convex is still their favorite work experience, even after they worked several different places since then.

I asked Jason Eckhardt recently why Convex was his favorite job. He started as a co-op student, writing software tests for the compilers. He says,

I grew a little bored and decided to not only find the defects, but then go isolate the assembly code that caused the wrong answer. Then I thought I could accelerate the codegen effort by just fixing the compiler bugs instead of merely finding them…. I don’t know any other place where I could have gone from junior co-op to compiler developer (on one of the world’s most advanced compilers, no less) in such a short time and with amazing support from my supervisors and peers–including the ‘compiler guys’ who were remarkably tolerant of me getting into ‘their’ code before they even knew me.

He also mentioned a supportive manager, a highly cohesive and friendly team, a tremendous amount of technical growth, and the freedom to spend the time to research the right solution to a problem. Individually, none of these things are terribly unusual to see in a company, but perhaps they’re not often seen all in one place.

Was Convex my favorite job? Actually, my all-time favorite job was as a temporary laborer with the Moving and Hauling department at the University of North Texas. You want a sense of accomplishment? Move 300-pound desks upended on a dolly single-handedly down three flights of stairs. I felt a real, concrete sense of accomplishment from that. But as far as bit-twiddling goes, Convex ranks right up there. After all, I haven’t talked to anyone from Moving and Hauling since I left that assignment. If they were to shut down the Moving and Hauling department, I doubt I’d shed a tear. Plus Moving and Hauling didn’t have any supercomputers for me to play with. So I save a special place in my memories for Convex.

Originally published in the Tejas Software Consulting Newsletter, v3 #2, April/May 2003