========================================================
FreshMeat #8 from Steve Portigal

               (__)                     
               (oo) Fresh                  
                \\/  Meat

FreshMeat. It’s free as a bird now, so join in!
=========================================================
A lazy journey through mistakes made and lessons learned
=========================================================

It was a hot Toronto summer, late in the 1980s. I was
wearing shiny dress pants and a sock tie, sitting in a
big downtown office tower. I can’t imagine it, but I may
very well have been fresh-faced.

Yes, I was a summer intern.

I worked in the computer support department of a bank
that had offices across Canada. I provided technical
support for anyone who had a computer problem, be it
hardware, software, DOS, what have you. This was
pre-Internet, so there was no way to know anything
about the state of their system except what they were
able to tell you. It was a challenging job, and gave
me a real sense of user empathy.

As part of my internship, I was asked to develop an
application for one client, a woman who was using a
spreadsheet to manage data for her investment
customers.

A spreadsheet, for those that haven’t used Lotus or
Excel (or VisiCalc), is basically just a bunch of
columns of data. Across the top may be headers such as
name, date, opening balance, etc. For example, I use a
spreadsheet to manage my collection of live music
recordings, so I have headers such as band, date, venue,
number of discs, comments. Each row, therefore, is a
different “record” in the database. It’s quite cool
because you can sort it by any field, or look at certain
subsets of all your data (originally, spreadsheets were
described as “what-if” programs).

We decided to move the program from Lotus (a spreadsheet)
to dBase IV (a database program that had the ability to
write programs that would add, delete, sort, search, etc.

The client sent me her spreadsheet (I guess she must
have put it on a floppy disk and mailed it to me) and
I sat down and spent several weeks putting together my
dBase program (to be really trivial, I think we used
something called Clipper that made actual “programs”
out of dBase code). I built in all the great functions.
ADD a new record. DELETE a record. And, the good ol’
standby, CHANGE an existing record.

I did a really nice job. The program offered you three
choices (ADD, DELETE, and CHANGE) which you could
select by pressing 1, 2, or 3. I think I was wise enough
to include a function that would let you quit the program.
When you made your choice, you would see a new screen
that said something like “Enter the number of the record
you would like to delete” and had a little space to type
it in. I’m sure I even had confirmations before deletes,
and feedback to tell you that your record had been added.
All this without a single course in user-interface design!

A few days before the end of the summer, I delivered it
to the client, still never having met her, or discussed
her expectations. I got a very nice phone call a few days
later. She was very appreciative of all the effort, but
she politely informed me that it wouldn’t be much use to
them, because of the way they used their current solution,
the spreadsheet. They would typically scroll very rapidly
through the data, looking for “flags” that they had
embedded – two or three character codes they placed in
front of the customer’s name to help them anticipate
certain actions. My wonderful front-end made that entirely
impossible.

And thus endeth the summer. Many successes and one failure.

But it was to be more than a year before the reasons for
the failure really became clear. Back in school, I
encountered my first course that considered the human part
of software – the user. I was struck with a ton of bricks
when shown that the people who make any kind of stuff
(revolving doors, stairway railings, library searching
software) are responsible for ensuring that their intended
users can actually make use of the thing.

Whoah.

And then my software development experience came into sharp
relief. I had made dozens of assumptions without realizing
it. I had never before grasped my own responsibility to
step outside myself in order to understand how that program
was going to be used. This second ton of bricks hurt just a
little more. But it changed forever how I looked at the
process of designing anything.