Sunday, October 26, 2008

Favorite Projects Series, Installment 1

I've been spending quite a bit of time these days thinking about what exactly makes a software project a good project to be on. Ever since I became a computer geek in 1980 with the purchase of an Ohio Scientific C1P from Commsci Corporation in Manchester, MO,



I've loved working with new technology, and using new, cool stuff. There are a number of projects that have been great experiences from that perspective, and I'll get to those later. But there's one that I always talk about when I'm asked what are some of my favorite projects, and we should look at that one first, and what it was that made it one of those most memorable projects.

In 1994 I was still working at Washington University, and more specifically, was doing some work for the School of Arts and Sciences. The plan was that I would sit and work in the department instead of being at a desk in the IT department. I had been up there for a little while, and we would identify different things that needed addressing.

So it turned out that there was this task that Cindy N. was responsible for that had to be done every year. It had never been automated, so she was spending two-and-a-half weeks every year manually completing the task. She dreaded it for weeks ahead of time every year, and made an otherwise happy job for her become miserable for several weeks.

Every year, Cindy had to review prospective students' records online, evaluate for what student aid they were eligible, then type up a letter inviting them to apply and detailing this information. As you can imagine with all of the manual work involved, there were going to be mistakes, and that's part of what she agonized over.

So, applying the technology at the time, we wanted to assemble the information available from an IBM mainframe to produce all of the letters and mailing labels needed. With today's technology, that's quite easy, given how everything's networked together. Even then, it was NOT rocket science. I had learned C, and wanted apply it to the problem of massaging the data into CSV format. We had a mainframe running the CP/CMS timesharing system (an early implementation of virtualization, which is in common use today), and that machine was the only place where we could run a C program.

We had to copy data from one mainframe to the CP/CMS mainframe, and if I recall correctly, we loaded the data into a FOCUS database, then extracted it from there onto the CP/CMS system. The mainframe with the data was not directly accessible from the Windows PC where we would run the mail merge into Word, but the CP/CMS mainframe was.

In CP/CMS we ran a C program that would extract the data and produce a CSV-formatted file, which we then downloaded to the Windows PC.

On the Windows PC, we wrote a non-trivial Basic for Applications script that would choose the appropriate paragraphs to include for each letter, depending on what aid would be received, and apply it to that letter, along with supporting detail. We would run the script to produce a single, long document that could be visually verified for accuracy.

Cindy would run this process, verify the results, and print the letters. What had been a painstaking, error-prone (no fault of Cindy's) two-and-a-half week process became a one-and-a-half day process that produced much more accurate and timely results. What had been a miserable, dreaded, yearly task became just another simple task to be performed.

Not surprisingly, this changed everything for Cindy. Though not technically the most challenging project I've worked on, it is one of the most satisfying projects I've ever done. Why? Well, like many people that get into software development (or many other careers), I want to change the world, and change it for the better. Realistically, I probably won't do that, but I can change my little corner of the world, and this is one project where I did change my little corner for the better. I worked directly with a user, understood the need, met the need, and saw the benefit that I provided, one human being to another. In some small way, one person's life was better because of what I did, and I got to see it happen.

One of the core tenets of today's Agile development processes is continuous, daily, user interaction. I've seen this be effective from 1983 when my software development career began at Washington University with my first user, Neldeane P.

No comments: