Well, no sooner do you finish something than somebody wants something new. ;-}

Suzanne and I have finished the first chunk of work we were doing on the Servicing Mission software changes. Now it goes to an independent test team.

The testers will try to find problems with the new software by running normal data, and "known bad" data through the system. We should correctly handle the good data, and report errors with the bad data.

This is basically the same testing Suzanne and I did before we delivered our changes, but we want somebody who _didn't_ work on the code to take a fresh look, and find things we might have missed.

While that's going on, we're starting on new things.

Suzanne will be working with Mary (another person on the Archive Team -- not my wife Mary.) on a new validation program, and I'll be working with Scott on what we call "multi-subrequest ingest."

Scott and I are going to have a conference about it right now....

-pause-

...and we're done. Scott and I talked for about half an hour about how we want to handle "multi-dataset" requests.

Remember the "phone book server" example? We had one "server" looking up phone numbers. You gave the "server" a request on a 3x5 card. What we're going to do is like letting you put more than one phone number on the 3x5 card.

Currently when we add data to the Archive, we do so one dataset at a time. (A dataset is a collection of files for one observation.) For the new instruments, we're going to let related datasets come in together.

For example, to make a color picture with HST's greyscale cameras, you would have to take three or four images through multiple filters. That would make three or four datasets, and the Archive would get three or four Ingest Requests.

For the new instruments, all those datasets would come in a single Ingest Request called an Association. That way we can put information in the database to tell astronomers that this group of images is related. Then they'll know that to get all the information about an observation, they should retrieve the entire Association.

Scott will be working on the program that takes this request and starts it through the system; I'll work on the other programs that do the rest of the work of validation, writing to optical disk, and putting information in the database.

But complicating all this is that Suzanne and Mary are working on the new Validation system, and to make the new and old Validation programs compatible, Suzanne needs to change parts of the old Validation program!

Suzanne and I have already talked about those changes, which I'll be working on while she's away at a training class this week.

This is how we usually work. We have small teams of two or three people working on each little project, and then we have to integrate our changes with the other little teams. There are nine of us on the DADS part of the Archive Team, and three on the Starview part, so there are typically four or five little teams working on four or five projects!

This is why communication among the team is so important. We almost never work alone -- we always are working on a problem or project with two or three other people -- and the teams may be working on the same or related programs.

So in addition to knowing some math, and lots of programming skills, we have to be good communicators. We send each other e-mail, have little conferences among team members, and (as a last resort) have a team meeting where we all get together to go over somebody's design proposal. For those meetings one of us will prepare a presentation, and then we'll all discuss the design, problems, and possible improvement.

So in addition to learning math and computer skills, we have to learn to write well, communicate ideas, and give presentations.

I go around telling people that while writing code is what we do much of the time, it is the least important thing we do. The most important is communicating innovative solutions that meet our users' needs.

After all, if our stuff doesn't work, nobody can get the pictures!