|
|
42 Years as a Software Engineer
by Owen Weber
On January 24th, 1977, I began my career as a software engineer. This article documents the
highlights of my career. (It's quite lengthy, but you can just skip the boring parts.)
Table of Contents
I graduated from Okeene High School in Okeene, Oklahoma in
1973. I knew that I wanted some kind of a career related to
mathematics. However, at that time, the only occupational
choices seemed to be an accountant or an actuary. I had taken
an accounting class in high school but I wasn't too interested in it, and
I wasn't even sure what an actuary was. However, when I was a
senior in high school, my physics teacher, T. J. Williams, had taken me
to Oklahoma City to hear Wernher von Braun speak. He was the German-American engineer and space architect
who invented the V-2 rocket for Nazi Germany and the Saturn V rocket used in the
Apollo manned lunar missions for the United States. I was intrigued by him, and a possible future in the space
industry, but I neither gave it much thought nor had any idea of how to pursue it.
In the fall of 1973, I entered college at Southwestern State College (SWSC) at Weatherford,
OK, which later became Southwestern Oklahoma State University
(SWOSU). In my second semester at SWSC, in the spring of 1974, I
noticed the brief "Computer Science" category in the course catalog. Like most people, I had
never seen a computer. There were virtually no computer jobs
yet, and I didn't know that Information Technology (IT) was about to become its own huge industry.
I decided to try it, so I enrolled in FORTRAN I taught by Dr. Benny
Hill. I didn't know Dr. Hill very well, but he made learning
fun, and he was very patient in teaching the radically new concept of
computer programming. After a few days and weeks of being
somewhat intimidated by the way computers worked, I finally understood
what was going on, and I fell in love with it. The idea of
feeding input into a computer, letting it do all the work by churning
through a series of calculations, and receiving printed output from it did indeed seem to
have potential for being a very powerful tool. Thanks to Dr.
Hill (and subsequently, Dr. George Atkins) I was on my way to being one
of the many pioneers on the forefront of the IT industry.
(back
to the Table of Contents)
In 1964, IBM had introduced a new generation of computers.
The IBM 360 was at the high end of these computers, but by 1974 they
were still so expensive that only the larger universities could afford
them. Fortunately, IBM also offered the IBM 1130 at the lower
end, but it incorporated the same new technology. SWSC had
an IBM 1130, and that's where and how I learned computer
programming. Amazingly enough, that computer had only 8
thousand bytes of memory, and it supported the whole campus.
A typical $500 laptop today can easily have 8 billion
bytes of memory--one million times more than what we had in college.
The entire computer lab was in a single room with about 300 square
feet of space. The IBM 1130 set at the front part of the room,
with a (huge) printer on the left; the Central Processing Unit (CPU),
the auxiliary storage (a mysterious 13-inch encapsulated disk) and a crude
typewriter interface in the center; and,
the card reader on the right side. Altogether, this computer
was probably about three feet wide, ten feet long, and four feet
high. In the back of the room were four (huge--and noisy) IBM
keypunch machines with a typewriter interface.
Some brief background on these keypunch machines is necessary
here. These machines utilized an algorithm patented by Herman
Hollerith in 1889. (This in itself illustrates the slow
evolution of computing for the next 90 years, until about 1980 when the
IT industry really exploded.)
Hollerith’s invention included the electrical tabulation of
data by punching rectangular holes into cardboard punch cards
(approximately 7" long by 3" high). Each card contained 12 rows and 80 columns,
and Hollerith's algorithm allowed for "any" number, alphabetic
character, or special character to be coded into each of the 80 columns.
As a result, each card could contain up to 80 characters of information.
In 1896, Hollerith founded a company called the
Tabulating Machine Company. In 1911, this company merged with
three others to form the Computing Tabulating Recording
Corporation. Then, in 1924, this company was renamed
International Business Machines Corporation (IBM) with Thomas J. Watson
as the first president of the company.
(back
to the Table of Contents)
So, when I wanted to write a computer program, I would write the
FORTRAN source code on a pad of notebook paper during class.
Then, at my designated lab time, I would go to the lab, open
a box of these Hollerith punch cards, and load a stack of them into the
keypunch machine. Then I would sit down and carefully type my
program, one line per card, and the machine would punch the appropriate holes
into each card, according to Hollerith's algorithm, which was readable
by the computer's card reader. Then, after a special "data"
card, I would continue typing the data that I wanted my program to process--again,
with one piece (row) of data per card. Sometimes the
resulting stack would contain hundreds of cards for a single program.
For example, suppose I wanted to write a program to calculate the
results of a presidential election; i.e., given the total number of
votes for Candidate 1 and Candidate 2 in each state, I wanted my
program to show the total number of votes cast for each
candidate in all 50 states. The pseudo code for my stack of
cards might look something like this:
1 TotalCand1 = 0
2 TotalCand2 = 0
3 If we have reached the end of the data cards, then GoTo line 8.
4 Read values Cand1 and Cand2 from the next card.
5 TotalCand1 = TotalCand1 + Cand1
6 TotalCand2 = TotalCand2 + Cand2
7 GoTo Line 3
8 Print TotalCand1, TotalCand2
9 Special card; i.e., data to follow
10 92176 54231 // Alabama
11 12347 22978 // Alaska
Lines 12 through 59 would be similar data cards for the remaining 48 states
Then I would (carefully) take my stack of cards, in the order in which
I had typed them, and place them face down into the input area of the card reader
on the computer, and secure the cards with a weight on top of
them. I would press a "Start" button on the card reader, and
the card reader would read the cards, one by one, and I would retrieve my stack
of cards from a bin on the side of the card reader. Of
course, a card jam would frequent destroy a few cards and I would have to re-type them and try again.
Then the CPU of the IBM 1130 computer would process the information
retrieved on my cards. It would treat the card reader input
as a computer program until it read the "data" card, and it knew that
the subsequent cards were to be used as input for the
program. Upon recognizing that I had written a program in the
FORTRAN language, it would load the FORTRAN compiler software from the
(huge) auxiliary storage device, and the compiler would process my
program. If it compiled without errors, it would then process
each data card against the compiled (Assembler) code, and it would
print the results (at about one line per second) on the huge
printer. This was a typewriter-style printer that would
actually print with typewriter keys, one full line at a time, so the
printer made a fairly loud noise each time a 120-character line of output was
printed, as up to 120 typewriter keys would simultaneously hit the
paper through the printer ribbon, creating a rhythmic sound as it printed one or two lines per second.
On the other hand, if the compiler detected an error in my program, it would print a crude error message on
the printer. I would then find the card that caused the
error, re-type any needed new cards, and replace the old cards
in the stack. Then I would try the modified stack of cards on
the computer again. So, this is how Dr. Hill taught me to program computers.
Here's a project that I did for the Electoral College results of the
1976 presidential election that Dr. Adkins had published in the paper:
College Electoral Map_1976. This was printed on that huge line printer. It illustrates how far computer graphics have come.
Some of the additional computer courses that I took during my college
years included:
Advanced courses in FORTRAN - A scientific-oriented
programming language
Courses in RPG - A business-oriented programming
language
Courses in COBOL - A
business-oriented language, actually assisting the college
Assembler - A low level programming language
System Simulation - Simulating ships approaching and leaving
a dock, etc.
SWSC still did not offer a degree in Computer Science, as only the
larger universities did. As a result, I graduated with a B.S.
in Math, with a minor in Computer Science, in the fall of 1976,
although I actually had more hours of Computer Science than of
Math.
During the fall of 1976, I applied for jobs by sending (paper) resumes, letters,
and
transcripts to various companies. Several prospects were
immediately interested, and I had early interviews with the
following companies:
Phillips Petroleum, Bartlesville, OK
Texas Instruments (TI), Dallas, TX
Burroughs, Detroit, MI
Resume_1976 (Note the job experience section.)
(back
to the Table of Contents)
By December, I had received job offers from Phillips Petroleum and
Burroughs, but, disappointingly not from Texas Instruments.
In addition, I had received rejection letters from many companies that
wouldn't even grant me an interview, including IBM (IBM_Rejection_Letter). I had
ruled out Burroughs because we didn't want to move to Detroit, so I
was beginning to assume that I would go to work for Phillips.
However, as time was running out, IBM decided to give me an interview
with their Federal Systems Division (FSD) in Houston, TX.
When I interviewed with these companies, I didn't really know what was
going on. I didn't know what to expect. I didn't
know anything about the companies or their industries, and I had had no
coaching on how to conduct myself during interviews.
(Consequently, I believe that's why I blew the interview with
TI.) When I
interviewed with IBM in Houston, I was more enamored with the
possibility of working for IBM (which seemed like the epitome of
computer programming companies) than I was with the job
itself--programming on their
NASA space shuttle contract for the first shuttle mission. I remember interviewing with one
manager named Sol Solomon who helped me to understand more about
what I might be doing, but I still had no real idea what would be involved,
or even what it would be like to work for a large company.
I was nervously waiting to see if I would receive an offer from IBM (my first
choice). I actually had two letters prepared for
Phillips--one accepting their offer, and one rejecting it. Finally,
at the last minute, IBM made me an offer as a "Scientific Programmer,"
and I accepted. I would start with IBM's FSD in Houston on January
24th, 1977 for a salary of $263 per week. (Although this was only about $13K per
year, it was three times more than I had ever made in my life).
(back to the Table of Contents)
Houston--Developing Onboard Space Shuttle Software (1977- 1981) (skip to next section)
So, I made the 550-mile move away from home and moved into an apartment
in Nassau Bay, TX, just outside of Houston. It was right next to
a bay off the Gulf of Mexico, and about three blocks from NASA.
Karen still had eight weeks of class work to complete at SWSC before she could join me
and begin her student teaching at Clear Creek High School in League City, TX. We
moved to League City later that year. I was 21 years old and I felt like I was on top of the world.
IBM was apparently very aware that we new-hires were quite green,
especially in an emerging industry, so their first order of business
was to give us eight weeks of intense training in a Beginner
Programming Training (BPT) class. There were 13 of us in my
class, and we were sort of on probation until we made it out of that
class. It was indeed valuable training, and we each emerged
from that class with a job title of "Junior Programmer." We
were each expected to excel enough in our jobs during the first year in
order to receive our first promotion to "Associate
Programmer."
About half of the class was assigned to the Ground-Based Shuttle
systems (GBS), and half went to the Onboard Shuttle systems
(OBS). I was assigned to OBS on the Guidance,
Navigation, and Control (GNC) project. My first manager was Nelson Harbison, and my
second-line manager was George Mueller. I shared an office
with Waldon Scott, a veteran Staff Programmer. Due to the nature
of our work, I also had to acquire Secret security clearance with
the federal government.
(back
to the Table of Contents)
Inertial Measurement Units (IMUs) (Boring--Celestial Mechanics
Stuff) (skip to next section)
My first
programming project was for the Redundancy Management (RM) of the
Inertial Measurement Units (IMUs). As I quickly learned, an
IMU was a sensing device that was a key component of the navigation
system of the shuttle. The shuttle had three IMUs,
and each one included a gyroscope and an accelerometer.
Basically, the gyroscope indicated the location of the shuttle (as a
vector in three-dimensional space) and the attitude of the shuttle
(the position/direction in which it was moving). The
accelerometer indicated the rate at which the shuttle was accelerating
or
decelerating in that direction. The various computer programs
on the shuttle ran anywhere from one hertz (once per second) to 25
hertz. The IMUs reported data to the software at 6.25 hertz, so
the IMU software ran six times per second.
Since there were three IMUs, the RM software was necessary in order to
reconcile any conflicting measurements reported by the IMUs for
determining the true position, direction, and acceleration of the shuttle. This was standard operating procedure for the
shuttle--to have multiple (backup) hardware devices in case of a
failure. With the IMUs, the function of the RM software
included determining if
an IMU had failed; which
of the three IMUs had indeed failed; and, to subsequently ignore
any data from that IMU.
How was this accomplished, especially since I had only minimal training
in celestial mechanics? Well, fortunately, we had scientific
analysts who understood all of this. So, NASA would give the
requirements to our analysts, and our analysts would give me detailed
specifications--almost pseudo code. So, simply by knowing
the HAL-S programming language (a PLS-type fourth-generation and top/down
structured language), I would translate the scientific specs into
software
code.
Although I was on the frontier of software technology, our process was
still quite crude at that point (a somewhat scary thought when
considering the delicate requirements of sending humans into space and
returning them safely). I would sit at my desk and figure out
how to write the required programs. Then I would go to one of
several small keypunch rooms, most of which contained two keypunch
machines. After sometimes having to wait in line for a
keypunch machine, I would keypunch my program onto cards, one line
per card. Then I would write any specific instructions to the
computer operator on a piece of a paper (such as loading a particular
tape drive), and wrap the paper around the
stack of cards with two rubber bands. I would lay this
package on a specific table in the hallway, and a few times each day, a
courier from NASA would collect all of the packages from the tables and
take them across the street to the computer room at NASA. The
computer operator would run my program on their mainframe computers
(in a stand-alone environment) and send back (via courier) my stack of cards
along with the printed output from the program.
This was a very frustrating way to have to conduct business, because
the turnaround was so slow. I would typically get only one
chance each day to run my program. I remember constantly
checking to see if my printed output had been returned. I
would often be disappointed after waiting until the next day for my output, only to
find that I had made some silly mistake in my typing, or a card (often
bent in transit) couldn't be read by the card reader, etc.
When all of us had our programs in working order, then the SDL
(Software Development Laboratory) folks would integrate all of the
software and test it in the shuttle simulator at NASA. Of
course, eventually the software would ultimately be loaded onto the
(five redundant) computers of the space shuttle itself, and our
programs would navigate and guide the shuttle through the
atmosphere, into space, and back.
(back
to the Table of Contents)
After working on the IMUs for a couple of years (for managers Mary Cole
and Ed Zatopek), I transferred to the Flight Control area, working for
Harold Herbold. I found this to be much more challenging,
demanding a deeper knowledge of celestial mechanics and aerodynamics.
(An old NASA joke: "I don't know what's so difficult about it. It's not
rocket science... Oh, yeah, it is.")
Basically, while Guidance and Navigation read sensors such as IMUs,
the Flight Control system actually issued the various commands to move
the shuttle from where it currently was, to where it should be 1/25th of a second later.
Each mission consisted of three phases--ascent (liftoff),
orbit, and descent (re-entry into the atmosphere; i.e., flying basically as a
glider). Depending upon the mission phase,
different specific flight control tools
were utilized. During liftoff, our
code would send controls (3-D vectors) to the Solid Rocket Boosters
(SRB engines) and the three main
engines of the shuttle in order to accomplish all of the roll, pitch,
and yaw maneuvers required to launch the shuttle through the atmosphere and
into orbit. While in orbit, we controlled the flight by
issuing commands to the Orbital Maneuvering System (OMS) engines in a
weightless environment. During descent, we
controlled the shuttle by issuing commands to the ailerons and the
rudder, just like an airplane, as it entered the atmosphere, descended,
and landed on a long runway.
(back
to the Table of Contents)
Scarce Resources (Maybe not
Boring for Software Engineers) (skip to next section)
Unlike today, hardware resources were very scarce in those
days. Each of the five General Purpose Computers
(GPCs) on the shuttle had only 100,000 bytes of memory. As a consequence of
this, we programmers had to be very efficient in writing our
code. In fact, I can recall occasions, while testing
simulations, when I would have to write part of a program in just a few
bytes (maybe 10 to 20 bytes) of memory. Here's how that
went:
Our PLS programming language was a high level language, and a line of
PLS code might look something like this:
if (sensor_level >= 1.7) GoTo 7
This means: If the condition in the parentheses is true, then go
to line 7.
However, this PLS code then generated lower level Assembler code for
compilation/assembly and linkage editing. A line of assembler
code might look like this:
MOV AL, 1h
This might mean: Move the hexadecimal value of 1 into
register
AL.
It would take many lines of Assembler code to equal the above line of
PLS code because it's done one step at a time; i.e., move several
values to several registers, then do some compares, etc.
However, machine level code is the most basic (lowest level of code),
and the hexadecimal code for a line of machine code might look like
this:
4146FF40
For example, the "41" might be EBCDIC code for the letter "A"; "46" is
"F"; "40 is a space, etc. It is comprised of these one-byte
hexadecimal characters, usually in clumps of 4, 8, or 16
bytes.
This would then translate into binary code, as follows:
0100 0001 0100 0110 1111 1111 0100 0000
i.e., the "4" in hexadecimal (base 16) = the "0100" in binary (base 2),
etc.
Anyway, sometimes after the code had been compiled and loaded into
memory in the shuttle simulator, the programmer would be called upon to make a change, but
then it had to be in the form of a machine language patch. In
other words, I might be told that the code between memory locations
71,456 (bytes) and 71,536 was faulty, and I had to re-code those 80
bytes of memory using ones and zeros. I would send 80 bytes
of ones and zeros across the street with instructions for the computer
operator to patch those particular locations in memory with my new
code.
The mainframe computers at NASA were quite interesting. IBM
had introduced its line of IBM 370 computers in 1970, and they were
much larger and faster than the 360s. NASA had two of these IBM 370s at the
time, but they also had three of the older IBM 360 models--the same
technology I had learned to program on with the IBM 1130 at
SWSC. In fact, while I was with FSD, one of the 360s at NASA
had the serial number "2"; i.e., NASA bought just the second one ever made (for use on the Gemini and Apollo programs), and
I used it in my program development for the shuttle.
(back
to the Table of Contents)
The First Space Shuttle
Mission (Not Boring) (skip to next section)
The first space shuttle mission, STS-1, was scheduled for April 10th, 1981. I was among those that IBM
had selected for real-time support of that first space shuttle mission and maiden flight of Columbia.
The first orbital space flight of the shuttle sounds exciting, but the awesome responsibility hung like a
yoke around my neck. After all, we were about ready to fill a
huge fuel tank with liquid hydrogen; bolt a space shuttle to it; put
two men in that shuttle; and then light it--and this had never
been done before. So, tensions mounted as that date drew near and
it became all too clear that those holes I had punched into those
cardboard cards could mean life or death for the astronauts. In
fact, a couple of scary incidents did occur.
First, less than two weeks before the mission, on March 30, 1981,
President Reagan was shot during an assassination attempt.
Although this incident had nothing to do with our space program,
this was not at all clear at the time, so it made things very unsure
for us. Also, there's a certain bipartisan unity and patriotism
among defense workers (both in the Department of Defense as well as
among contractors) that I had never previously experienced (and that is
certainly not widespread today). It was sort of like being in the military.
When I would travel to places
like the U. S. Department of Defense in Alexandria, VA, or Rockwell,
International in Downey, CA, I would see the President's picture
proudly displayed in most offices, meeting rooms, and hallways.
Whenever a new president was sworn in, they would just as proudly
replace the pictures of the outgoing president with those of the new
one, regardless of their political views. The president was not
only revered as the Commander-in-Chief, but also as the ultimate head
of NASA. NASA is not technically a part of the
Department of Defense, nor of any other Cabinet-level department.
NASA's administrator reports directly to the White House, and of course the president recommends funding for NASA.
So, when President Reagan was shot, it affected morale. Most of us were old enough to remember President Kennedy's
assassination, and as the reports were leaked out about President
Reagan, we couldn't help but draw some analogies to President Kennedy's
situation. At first they said that President Reagan had not been
among those hit, and some of the first reports in Dallas had said the
same thing about President Kennedy. In Kennedy's case, reports
quickly followed that he had indeed been hit, but that we could all
take hope in the fact that they were rushing him to Parkland
hospital, a very reputable hospital. So, when the next reports we
heard about President Reagan said that he had indeed been hit, but that
we could all take hope in the fact that they were rushing him to
George Washington University Hospital, another very reputable hospital,
we became very skeptical about any ensuing reports that sounded
optimistic. Fortunately, of course, he recovered quite quickly,
but not before a few anxious moments at NASA.
The second scary incident occurred during the first countdown of the
STS-1 mission. Serving on the real-time software support team was one
of my greatest challenges ever. Behind the Mission Control room at NASA (that
most TV-watchers saw) was a smaller room for software support. During simulations and
real missions, we staffed that software support room (needless to
say--24 X 7), and we were at the beckon call of Mission Control, if any question or problem came up
concerning the software.
One moment of tension always occurred during the Flight Director Chris
Kraft's "roll call." At the beginning point of the countdown, and
at several key points during the countdown (and the rest of the
mission), he would contact each area (Guidance, Navigation, Flight
Control, Software, etc.) in a roll-call fashion. He would simply
say the name of that area, and he wanted to hear only one word in
response, "Go;" i.e., he didn't want to say, "Software," and then hear
"No go," or least of all any stammering around that would indicate any
unsure or unstable tendencies. It was a very intense and
demanding job, and I can remember the hair standing up on the back of my neck
whenever I would hear the voice of Flight Director Chris Kraft
in my headphones saying, "Software? ..."
Well, as I alluded to earlier, this scary scenario actually played out
during the pre-flight moments of the first mission as the space shuttle
Columbia set on the launch pad with astronauts Commander
John Young and Pilot Robert
Crippen onboard. I had worked for four years (with 800 other
IBMers) in anticipation of this moment.
I was in the software support room behind mission control when I heard
the countdown for launch suddenly stop at about T-20 minutes before the
main engines were supposed to fire. Something had gone wrong.
Everyone at NASA was frantic and nervous, and sure
enough, I heard the Chris Kraft's voice frantically saying,
"Software?..."
As I recall, it was the voice of my peer, Roger Demeny (an IBM
veteran), whose job it was to reply to Chris Kraft, "No go." We
feverishly began looking at downloaded hexadecimal memory dumps, paging
through software, etc. As it turned out, the issue had in fact been due to
a software (timing) error, but it was in the system software (thankfully not my area), and the
mission had to be "scrubbed" (aborted).
The error had been coded by one of my colleagues, and he also supplied the fix.
However, it took a matter of hours / days to get things back
on track and rescheduled. STS-1 was finally successful,
lifting off on April 12th, 1981 and returning from a 54.5-hour mission
on April 14th, 1981 (during which I went on basically no sleep).
I also recall some nervous moments during the descent phase of that first
mission. Throughout the history of the shuttle development, it was generally
thought that the tiles on the bottom of the shuttle were its primary
weakness. These were a special heat-resistant type of tiles
which were necessary in order to keep the shuttle from burning up as it
re-entered the atmosphere from space. The point of concern
was the glue that held the tiles onto the shuttle.
They continually had problems with this glue, and tiles would sometimes fall
off during testing. Nevertheless, they went ahead with the
mission. As the shuttle is entering the atmosphere,
there is a brief blackout period (maybe 90 seconds) when communications between the shuttle and the
ground are not possible. I remember how relieved we were on
that first mission when we once again heard the astronauts' voices, telling us that the tiles had
done their job. Everything was fine, although I
believe that a minimal number of tiles did indeed fall off, but not enough to cause any real problems.
One of the perks of my job was getting to meet some of the astronauts,
including one meeting with John Young (one of only 12 men to walk on
the moon) and Bob Crippen when they came
to our IBM facility for a presentation. On another occasion,
I traveled to Rockwell, International (who built the shuttles) in
Downey, CA to meet with some astronauts about some specific software
concerns that they had.
(back
to the Table of Contents)
Meanwhile, I usually received above-average performance evaluations
during those years at FSD. I was promoted to Associate
Programmer (Promotion_Notice_1977) after just nine months, and to Senior Associate Programmer (Promotion_Notice_1979) after two years.
I quickly became deeply immersed in the IBM culture. IBM
seemed like a company that would take care of me for life. In
order to reciprocate, and to always put our best foot forward to our
customers, male employees were expected to wear a dark blue or gray suit
every day, with a white shirt, and a "sincere" tie, and the women were
expected to wear dresses. This strict dress code continued
until Louis Gerstner, Jr. took over as CEO in the early 1990s.
(back
to the Table of Contents)
Tradition ran deep at IBM. Thomas Watson, Sr. had founded the
company in 1924, and served as the first CEO. In 1952, he was
succeeded as CEO by his son, Thomas Watson, Jr. (who later served both
as the National President of the Boy Scouts of America, and as the U.S.
Ambassador to the Soviet Union). In 1971, T. Vincent Learson
succeeded Watson as IBM's CEO, but he served for only two
years. When I joined the company in 1977, Frank Cary was
our CEO--only the fourth CEO ever of the company that was then over 50
years old. The other CEOs while I was still with the
company were John Opel, John Akers, Louis Gerstner, Jr., and Sam Palmisano.
(back
to the Table of Contents)
One of my colleagues was a veteran IBMer who had joined IBM as a CE
(Computer Engineer) in 1959, and he once related the story to me about
his first day with the company. IBM had hired 250 CEs who
reported to a large meeting room on their first day. My
friend said that the group consisted of 250 men (no women), all in blue
suits, white shirts, and ties.
Well, by the time I joined the company, big changes were (justly)
underway at IBM, as well as at most other large companies, largely due
to the Civil Rights Act of 1964. It was now IBM's policy to
make sure that they didn't discriminate against any employee based upon
ethnic background, gender, or age (and eventually, sexual
orientation). Employees were regularly and frequently
ingrained with related education, including programs such
as Equal Opportunity, Affirmative Action, and Diversity. I'm
proud to have been a part of the diversity movement that contributed to the
advancement of women and minority groups in the workplace.
(back
to the Table of Contents)
I recall how anxious I was to advance my career through
promotions. When I first started with IBM, I quickly noticed
that it was easy to discern an employee's level by his/her office and
desk. Employees who were at Staff level and below had to
share an office with another employee (each with metal
desks). Advisory level employees got their own private office
with a wooden desk. Above that (Senior level and beyond), an
employee's level was revealed by the size of his/her desk, and the
amount of overhang on it. I quickly made it my goal to reach
the Advisory level, and to have my own private office.
Another goal was to become a member of the IBM Quarter Century Club, an
elite group of IBMers who had 25 or more years of service.
(back
to the Table of Contents)
Another "benefit," although not officially a part of the benefits plan,
was called "full employment." This meant (unofficially) that
as long as an employee worked hard and kept getting good results on
his performance evaluations, he didn't have to worry about
losing his job. Officially, it was stated that no IBM
employee had ever been let go for "economic reasons" in the history of
the company (since it started in 1924). In other words,
nobody had ever been laid off at IBM. It was sort of like
having tenure as a college professor. I knew that I was a
competent employee with above average performance reviews, so I made
myself another goal: to retire from IBM with full benefits
after 30 years of service on January 24th, 2007, although that seemed
like a very long way off.
(back
to the Table of Contents)
Immediately after the success of STS-1, I applied for a
transfer. My mother had been suffering from congestive heart
failure for three years, and we wanted to move closer to her so that we could visit
her more often. Also, my job on the space shuttle was very
stressful, giving me prematurely gray hair. I had wanted to make
it through the first flight, and I did.
(back
to the Table of Contents)
I applied for several jobs in the Dallas
area. I learned about one of these jobs through an IBM
colleague of mine, Dan Kemp, who had recently transferred from Houston
to Dallas just as I was looking to do. I accepted that
position, working in the same department as Dan, in the new Las Colinas
development in Irving, about three miles from the old Texas Stadium.
We moved to Carrollton, TX, and I started my new job as
an Application Programmer on July 1st, 1981.
While FSD brought a lot of good press to IBM, it wasn't one of its more
profitable divisions. My new job was more in the mainstream
of IBM's core business. I was a software developer on a
product called IBM ADF (Application Development Facility). It
enabled our clients to customize their own applications on IBM
mainframe computers. On the IBM 370, programs were run on
operating systems such as VM (Virtual Machine) and MVS (Multiple Virtual
Storage). I programmed in the PL/1 language, another
fourth-generation language, using SQL (Structured Query Language) relational
databases (RDBMS). I wrote my first SQL query in 1981, and those same queries would still work in today's RDBMS.
Our customers were mostly large companies, including several large
banks. The idea was that ADF would allow each customer to
control exactly what happened at the point of a customer transaction,
in terms of data processing. Remember that this was before
everything was electronic, automated, and online like it is
today. Although our capabilities then seem crude now, I was
still working on the very forefront of technology.
In addition to working for a more profitable division, it was at this
time when I first became familiar with what we now call
e-mail. This was still about 15 or 20 years before the
internet, but IBM did have a sophisticated company-wide network where we could communicate
electronically with other IBM employees (at least in the U.S.).
So, I sent my first e-mail in July, 1981. I had a
crude, huge, heavy, black-and-white (green) monitor on my desk (these were later
referred to as "dumb terminals," because they only connected to the
company network, without any CPU or memory of their own). Not
only did we now have e-mail, but we also wrote our programs electronically
via this terminal, so I no longer had to use stacks of keypunch
cards. The difference was like night and day.
Instead of using a manual keypunch, I could just type the lines of code
into a file, save it, compile it, wrap the proper JCL (Job Control
Language) around it, and run it as a batch job on MVS.
One of my specific tasks was to improve the performance on a
sub-product of ADF called the Auditor. Even though I now used
mainframes, resources were still scarce, and expensive, and computers
were slow in comparison to what we have today. I had a lot of
fun seeing how efficient and fast I could make the Auditor, and this
experience taught me a lot about performance benchmarking. I
excelled at this task, and within a year or so, I received a promotion
to the Staff Programmer
level.
While in my ADF job, I traveled some, including trips to Tucson, AZ,
and my first trip ever to New York City. On the other hand,
one of the things that I didn't like about that job was "the
hotline." The members of my department would rotate handling
the hotline, which meant serving in the role of customer support, by
fielding phone calls from (sometimes irate) customers. I
never felt like I had enough knowledge of all of the functionality of
our complex software systems in order to provide the desired level of customer satisfaction,
especially when being put on the spot on a phone call.
I was a workaholic. I was so devoted to my work that when my
mother died in 1983, I only took two days off. On a Thursday, we
received word that she was probably dying. We drove to Oklahoma
after work that day, and she died that evening. I took
off Friday; her funeral was on Sunday; I took off Monday when we drove back
to Carrollton; and, I went back to work on Tuesday morning.
That's really sad.
(back
to the Table of Contents)
Interactive Satellite Education
Network (ISEN) (skip to next section)
I had been in this job for nearly four years, and I was not really
looking to change jobs. However, as it happened, our
next-door neighbor in Carrollton, Ed Pitrucha, was a Director (executive level
manager) with IBM. One day, his wife, Ann, invited Karen to a Tupperware
party at their house. While Karen was there, Ed mentioned to
her that he needed to hire a software specialist, and she indicated
that I might be interested. Ed had recently moved
back to the Dallas area from New York, where he had advanced so far in
the company that he was even rubbing elbows with CEO John
Akers. He now headed a department in IBM's Education Division
called the Interactive Satellite Education Network (ISEN). He
didn't need a programmer--just someone who could understand software
and act as a liaison with the vendor. In January, 1985, he
offered me a promotion to Advisory level, with my own private office
(which had been two of my goals since joining IBM), and I
accepted. Incidentally, that was the last promotion I ever
received.
ISEN was a sophisticated education network that IBM used for customers
as well as its own employees. There were four broadcast
sites in: New York City, Chicago, Los Angeles, and
Washington, D.C. There were 13 sites that could receive these broadcasts,
including these four broadcast sites, as well as nine other sites such
as in Dallas, Houston, Philadelphia, St. Louis, Boston, Hartford (CN), Minneapolis,
etc. An instructor would sit in a studio at one of the broadcast sites and teach a course
via satellite. At the receive sites, there was a satellite
dish on the roof and a number of 8-student classrooms, again all
equipped with the latest technology. At the front of each
classroom were two monitors--one showing the instructor, and one
showing his instruction material, foils, etc., along with a speaker
broadcasting the instructor's voice. So, there were video,
audio, and data signals being broadcast from the studio via satellite.
At each student's desk was an electronic device that would allow a
student to direct a question to the instructor. The student
would simply press a button which would send a signal back to the
studio, where a light would be illuminated, indicating that a student
at a certain site had a question. The instructor would
verbally acknowledge the question, and the student could then speak
directly to the instructor, with the audio of both the instructor and
student being broadcast to all sites. This was at
the expense of temporarily blocking the data line transmission, because
that line was now being used for the student's audio. The
idea was that the education could be just as effective as if the instructor was
physically in the classroom, while reaching more students across the
whole country, and minimizing travel (expense) for both the instructor
and the students. (Today, we use the Internet for this.)
Although the concept was simple, the implementation was not.
Our vendor was Hughes Aircraft, who supplied the communications
hardware, and their vendor for the required software was NCR, a company
based in Tokyo. I needed to learn how the software worked,
how to respond to software errors, etc. One of the perks was
that Ed sent me to Tokyo for three weeks in August, 1985 to meet
directly with the folks at NCR. In addition, although I didn't need to write
any ISEN software, I did write a nifty AI (Artificial Intelligence) VM application for IBMers for the
scheduling of ISEN classes.
This was the time in my career when I learned how to travel.
Not only did I get a trip to Tokyo, but with broadcast and receive
sites scattered all around the country, I made frequent trips to many
of those 13 cities, including New York City, Chicago, Los Angeles,
Washington, D.C., Houston, Minneapolis, Philadelphia, and Seattle
(where I was actually responsible for the building of a new receive
site). As I recall, I believe that I went to Los
Angeles and Washington, D.C. most often. I probably traveled
between 25% and 50% of the time, making two or three trips per month,
for one to five days each.
I've always said that Ed Pitrucha taught me how to travel. He was a big spender--one known to
splurge--and he had a big IBM budget to spend. I once
traveled to Philadelphia with him just so he could
eat at Bookbinders (a famous restaurant, and one of Ed's
favorites). On another occasion, he wanted to have
lunch in New York the next day, so he and I left Dallas at 7:00 AM,
went to the ISEN facility in New York just in time for lunch with
colleagues, and we were back home by 8:00 PM that night. This
was back before all of the metal detectors and other safety measures
were in place at the airports. I can remember sometimes
riding with Ed to the airport, getting out of the car, walking straight into the terminal
directly to the gate, and boarding the plane at the last possible
minute. Sometimes it made me crazy, but I did enjoy the
travel, although I didn't like being away from my family in the
evenings. (Ed got onto me after my Tokyo trip because I had
racked up some $300 in phone calls to Karen.)
It was during my ISEN years that I got my first "portable" computer.
It was called a Compaq Portable. It was about 24" X "24" X
6", and it had a five-inch black-and-white screen (that actually
displayed in amber-and-black). I did lug it home on some
evenings, but it weighed about 25 pounds.
Incidentally, I do remember a particular day that will always stick in
my memory. On January 28th, 1986, a colleague of mine, Mark
Reith, quickly stuck his head in my office and said, "Hey, we lost a shuttle." The Challenger had broken apart 73
seconds after the launch of its tenth mission, killing all seven crew members. I could
envision the roll, pitch, and yaw maneuvers of those main engines as it
exploded during the ascent phase.
(back
to the Table of Contents)
In 1988, I decided that I wanted to get back into
software development. It was relatively easy for me to find such a
job with IBM in Las Colinas. I had a lot of contacts in that group, plus they were
expanding in an effort to directly compete with a competitor.
Microsoft was about to deliver a new product called Microsoft
Office. Yes, this was the same Microsoft Office that so many
of us still use today, and that now has a monopoly on that market
space. IBM was determined to steal some of
that business away from Microsoft (especially since the sale of DOS
to Microsoft had gone so badly). IBM had developed its own
operating system for the PC called OS/2 (IBM's answer to DOS and Windows), and it was now going to develop a
complimentary office product called OfficeVision/2 (OV/2) to compete with MS Office. It
would include e-mail, a word processor, a calendar, a library, etc.,
just like Microsoft Office, plus the family of OV products would run on
virtually any IBM platform, from the PC, to mid-range hardware, to
mainframes. So, the job sounded intriguing.
Furthermore, when I was looking for a job in my previous organization,
I found out that the software development organization was going to be
moving from Irving to Westlake. Then I found out about a
clause in IBM's Moving and Living Expenses policy that turned out to be
very helpful. If a facility moves its location, and the resulting
move would cause an employee to have to commute more than 25 miles
one-way, then they were eligible for the full Moving and Living
Expenses package from the company. (This was back when IBM was still making lots of
money, and willing to spend it liberally--more about this
later.) As it turned out, this policy also applied to me, as
an employee joining (or re-joining) that organization. Since
my commute from Carrollton to Westlake would be more than 25 miles, I
was eligible. This meant that we could move and IBM would pay
our moving expenses, and even buy our house if we had any trouble
selling it, etc. This was about a $15,000 perk, and it
allowed us to build the house in Coppell that we still live in today.
So, I accepted a job as an OV/2 developer, and we felt like we had it made. I was 32 years old and we
had built our own new house, just like we had always wanted, and I had
a job with my own private office with an outside window and a view of the lake and the park. I
had the challenges of learning a new operating system (OS/2) and a new
programming language ("C"). In fact, OS/2 hadn't even been
announced yet, and our code name for it was "Winthorn." As a
result, the operating system was evolving as we were developing on it,
a situation which offered new challenges in itself.
Nevertheless, we were determined to beat Microsoft in this head-on battle.
I worked in several areas of the new product, including the calendar
and the library, and my travel even included a trip to
Toronto. However, my diversification was not all good
news. A major part of the reason that I jumped from one area
to another was because we couldn't seem to actually get anything
developed and shipped. Our development process was too
slow. We were stuck in the same development methodology of the old IBM, back
when it was the only kid on the block. Now that we had competitors
who were cranking out new products and new features every day, we
couldn't keep up. We were used to releasing updates every six
months, but our competitors were releasing every six weeks.
Sometimes, by the time we were ready to
release something, Microsoft had already released something even
better. Or, sometimes the evolution of our own operating
system seemed to bring us back to square one. As a result, I
found myself working hard to develop software, and then (repeatedly)
just throwing it all away and starting over. Eighty-hour
weeks were common, and sometimes I worked over 100 hours per week.
That's hard to do without severely cutting into one's
personal and family time. (Again--sad.)
One of the old-time analysts that I knew at Houston, Dick Lemmon, once
gave me an apt illustration. He said that if IBM hired him to
dig a hole, he would dig it. If IBM hired him to fill in the
hole, he would do so. So, from the point of view of my relationship
with IBM--work for hire--this might be OK. However, when assessing
what a repeated pattern like this will mean for the company's bottom
line, one should always keep an eye out for how it's affecting
profitability, and what changes might occur as a result.
Meanwhile, little by little, and somehow almost unnoticeably, IBM started
losing money. The quarterly earnings statements
didn't mean much to employees. Earnings might be down one quarter, or one
year, but there was always a reason to expect that they would turn
around the next quarter, or the next year. Life internally at
IBM remained plush, with unofficially guaranteed full employment, and
everyone fat and happy and spending lots of money on traveling, moving,
etc. However, Big Blue began major cost-cutting measures,
including incentives to encourage eligible employees to retire.
Then suddenly in 1992 everyone, including Wall Street, noticed that
IBM had been losing $5B per year for the last three years. ($15B was a lot of money
in those days.) Well, suddenly an unprecedented series of
events began unraveling:
- The price of IBM stock dropped from $160 to $40.
- John Akers (the last of the old-timers) stepped down as CEO, as he couldn't stand to make the
changes that he knew were coming, and Louis Gerstner became CEO for the
new lean IBM.
- New retirement benefits for future retirees that had been announced only a couple of years
earlier were terminated. IBM was simply not going to
carry through with what they had promised. Sorry!
- The cash incentives to encourage older employees to retire were
discontinued. If you hadn't retired by now, it's just too
bad.
- The Tax Deferred Savings Plan now made more sense. It had
been introduced as an "opportunity" for employees to "share in their
own retirement investment." However, now it was apparent that
things were quickly moving towards a point where employees would be
solely responsible for their retirement pensions, with no help from Big
Blue.
- Less profitable divisions were sold, including the Federal Systems
Division, so IBM no longer had a hand in the space shuttle, defense
contracts, etc.
- Then came the bombshell--full employment was no more. In
one day, IBM reversed course, from full employment to the announcement
of the largest layoff in corporate history. IBM would soon
lay off 110,000 of its 400,000 employees. We were
told that on the following day, every IBM manager was going to call each
of his employees into his office and let them know whether or not they still
had a job. (There were few good nights of sleep that
night.) Although I was told that I still had a job, four of
the ten members of my department were laid off immediately; in some
departments, 70% were gone. I knew one man with 18 years of
service who was laid off with no pension
or anything. (I had 15 years at the time.) It was all just gone for him, and that could
easily have been my fate as well. I called it "The Purge of
1993." Ironically, this was the same year that Thomas Watson,
Jr. died. He had been a driving force for "full employment"
throughout IBM's history.
These events remind me of the squabbles in the press today about states
going broke, municipal bankruptcies, public unions and pensions,
private and corporate debt, the federal deficit, etc. People
who have been promised a pension may not get the full pension that they
were promised. Future Social Security recipients may not get
the full amount they were promised. And, people are
outraged. How can they not get what they deserve--what they
were promised? Why is this the case? Well, it's
because things change,
and sooner or later, everything
has to be paid for, in one way or
another. If IBM fat cats and retirees spent all
of the future retiree's money, then that retiree simply doesn't get his
money. If public unions keep pressuring our government bodies
for money they don't have, then it has to stop somewhere. If
debt gets out of hand, then somebody, somewhere, sometime, has to pay
for it. Is it fair? No, certainly not in terms of
honesty and integrity. Is that the way it is? Yes,
it's called "change," and sometimes we just have to learn to live with it.
(back
to the Table of Contents)
Well, about this time, my career took a change as well, and for the
better. I moved out of software development, and into
software testing--Quality Assurance (QA). I was really
having trouble with continually writing software only to throw it
away. As a result, my performance evaluations were suffering
(for the first time in my career), and I thought I needed a
change. As a brief explanation for those not familiar with
it, (the "Waterfall" methodology of) software development included
several phases which may be generalized as follows:
- Requirements - Gather the requirements from (perhaps potential)
customers as to what they expect the software to do.
- Design - Business analysts produced the high-level specifications
from the requirements; and, developers produce the low-level
specifications from the high-level specs.
- Coding - The developers write the code and perform unit testing on
their own code.
- QA / Testing - The Quality Assurance team performs function, integration,
systems, performance, and regression testing, creating necessary
defects (bugs) and testing
the fixes for those defects.
- Support - The support team supports the customers who buy the
software. They field questions from the customers, and
provide feedback on defects and enhancements for repeating this whole
process for the next release.
I have worked in every phase of the software development process, and
in 1992, I discovered that my real calling is software
testing.
I love trying to break software, and I'm very
detail-oriented, and that's critical in software testing.
Plus, I think that my
experience as a developer adds value to my testing.
I've always prided myself in writing defects from a developer's
viewpoint, so that the bugs are easy to understand and to reproduce
without too many questions slowing down the process. Paraphrasing
from what I once heard a baseball player say, "God made me
to be a software tester, just not a very good one."
I recall hearing a story from some IBM veterans early on in my career
at IBM, and it really stuck with me. The story had to do with
the development of the IBM 360 system. As with most new
products, the development team kept having trouble--finding too many
defects, missing deadlines and dates promised to potential customers,
etc. Well, management finally made a decision:
Whenever the number of open defects dropped below 1,000 known software
bugs, they would release it, and they did. This always amazed
me, that they would take such a risk. I believe that this
story always motivated me toward the software testing side of the
business--to help ensure the utmost quality in our products.
Anyway, from 1992 to 1995, I stayed in the software development
laboratory as a software tester, although during this time the lab
moved from Westlake to Southlake. I excelled in software
testing, including successful testing of products such
as Address Synchronization/2. However, I faced a couple of big
problems:
- Because I was at the Advisory level, I was called upon to be the team
leader
for testing teams, and I did not excel at leadership. My
strength was in software testing, but I wasn't
allowed to do what I was best at, and what I enjoyed. I have
always performed best as an "individual contributor," in the most
literal sense of that phrase.
- Microsoft was clearly beating us. We were still creating
software and just throwing it away.
(back to the Table of Contents)
In late 1994, I made a business decision. In my view, the
writing was on the wall for the Southlake lab. Microsoft had defeated
us, and the company would not be able to afford to keep throwing money away on
OV/2. I decided to look for another job, internally within
IBM. Although the course I took had problems in itself, I
will always look back on my decision to leave the Southlake lab as the
right decision. Shortly after I left, later on in 1995, the
lab was indeed closed down, abandoning any further efforts on the OV set of
products.
(back
to the Table of Contents)
There had always been another perk with the deep traditions at IBM.
Each employee was given considerable flexibility in defining
his own career path. Upon taking a new job within the company,
he was expected to spend a reasonable amount of time in that job.
Then, after doing so, he was free to look for another job
within the company. So, far, I had been changing jobs within IBM
about every four years, probably about the average for IBM employees at that time.
My new job was in Irving, just down the street from my
house. I was the team lead for a small, but growing, software
testing team. Our software product was one used only
internally by other IBMers (marketing and sales personnel) in tracking
hardware and software sales. The demands of my job were once
again more for leadership than for the software testing that I enjoyed
so much. My duties included building a team of testers
(mostly contractors); i.e., interviewing, and making recommendations for
hiring, firing, and performance evaluations. Still, my job
rolled along pretty well for about a year, with very little interface
with management, which was a break in the normal tradition at IBM,
where each employee developed a close relationship with his
manager. I really didn't even think that anyone noticed me much, but that was all about to
change.
One day in 1996, I got a surprising phone call from a high-level, but
technical, IBM executive who considered himself to be a QA expert.
I knew him by reputation only. First he belittled me for
not making / saving IBM anywhere nearly as much as he had. Then
he abruptly told me that I had a new manager, in another
division of the company, and that I was to report to her office the
next day. Well, OK. I had often had managerial
changes, and they usually came by way of a seemingly abrupt
announcement, but there was usually
very little change in my day-to-day duties and expectations.
I reported to my new manager's office on a Thursday afternoon for what
I thought would be a get-to-know-you meeting. Instead, the
whole meeting was a surprise and a blur from the beginning.
The best word for describing my new manager's attitude was
"curt." She didn't politely welcome me into her
office. She simply laid down the law to me, without
explaining the reasoning behind anything she said, and without
welcoming any questions.
She simply told me that I was no longer the test team leader
on my current project, because I was needed more urgently on another
project. This was effective immediately.
(This was another anomaly because changes within the company had
usually been by way of smooth and lengthy transitions.) I was now a testing
consultant on a marketing and sales team, and I was to prepare for life on the road. I was
to meet up with my new team on Monday morning, in California, and work with
them there for the next three weeks on our first project. It was such a blur that
I cannot now recall whether it was in the LA area or in the Bay area.
I remember asking whether or not I had a choice in the
matter, and being told that I didn't. In other words, I
believed that my only recourse was to leave the company. Looking back, I still don't know for sure
what I should have done, since one's first-line manager was always his go-to person at IBM. I
probably should have taken the issue to upper management as an
infringement upon one of IBM's five Basic Beliefs--Respect for the
Individual, but I didn't want to make waves, especially in the "new" IBM where full employment
no longer prevailed.
So, I did as I was told. I was already in California before
I even figured out what my job was. The IBM Services Division
was creating software for utility companies, and our first customer was
PG&E (Pacific Gas & Electric). I was on a
team with five other people--a marketing guy, a sales rep, etc., and I
was the testing consultant. Now, I wasn't sure what a testing
consultant was supposed to do, and I didn't know how utility company
software was supposed to work. Nevertheless, I was supposed
to help sell it to PG&E by showing them how we were going to
perform integration and system testing on our software, in their
shop.
Now, imagine yourself, whether an IT person or not, in my
shoes. As you're reading this, you have about as much
information about my new job as I had. I was
absolutely clueless. I had no training in how to be a
consultant, in the utility industry, or in our (potential) software;
and, I knew that I wasn't a good salesman. I suddenly
felt like a country dog in the city, either giving a (clueless)
presentation to the customer, or locked in a hotel room with five IBM
sales people working on a "team" proposal.
Well, I don't remember it all too well, but I believe that the travel
part turned out not to be as bad as I expected. After a few
weeks (and I don't know how many customers) later, my job somehow
materialized into staying in our Dallas office and supervising dozens
of people that I didn't know who were either testing or actually using
our utility-related software that I knew nothing about, with no support
from management. Occasionally I would get freed up from supervising long enough to look
at the software and try to find a couple of defects. However,
most of my time was spent just hating my job and not wanting to come to
work in the mornings.
I guess I'll never know what really went on with all of this.
All I know is that it jolted my confidence in IBM. I knew
that I had to change, or I'd go crazy. However, I just didn't
know what to do. The IBM culture had been turned upside down.
It was no longer a place where I could enjoy my job.
It's like I couldn't think straight (and the year of
1995 had been an incredibly tough year for me in my personal
life--emotionally draining--from just about every
perspective). I was desperate for a change, but there seemed to be very few options in
the new IBM. In early 1997, I made all of the internal contacts that I could think of, I had a couple
of interviews, and I ended up accepting a job in software support,
working for Randy Stone, an old friend from the lab.
(back to the Table of Contents)
Now, you heard me right--software support.
Remember? That's where I had to: "... support the
customers who buy the software, and field questions from them,
etc." That's in addition, of course, to being a team
leader of other support folks. Does that sound like
me? I wasn't given any time for training, and it was a nasty and explosive
situation which seemed to be feeding on itself daily. How does
one answer questions from customers (to their satisfaction) concerning software that he
doesn't understand? How does he leverage the knowledge of his
subordinates without looking like a fool himself?
Furthermore, how does someone without real leadership skills actually
lead a worldwide team of 14 support personnel scattered from Dallas and
Austin to Belgium and Tokyo?
(Notice how the first part of
this article is much more detailed than this last part. That's not
intentional. It's just that something, at this point in my career, was preventing me from
knowing, learning, and remembering the details of my own job like I did
earlier in my career, and there simply aren't many of those details to recall.
One of my problems was that I was just too good at
"faking it.")
So, what was the problem? I was supporting a product that was
later called WebSphere, IBM's strategic platform for building
applications on the internet. All of our products
were now being written using object-oriented (OO) programming
languages, such as C++ and Java. Now, remember when I
mentioned that I excelled in using "top-down"
structured programming languages? Well that's about the
opposite of what OO languages are. They just never made sense
to me, and I never had the proper training for them, or something
was preventing me from learning. To me, OO
languages were like good programming languages gone
bad. As a result, most of our customers who called me with
questions already knew more than I did. How much less
comfortable do you suppose I felt when my subordinates would ask me
questions? So, what should I do? My answer was,
"Travel." If you're on the road, then nobody can track you
down to ask you about something that you know nothing about.
I was so out of my element. In June, 1999, I even had to
serve as the moderator for an "All Things Java" webcast. I
broadcast the event from a satellite center in Dallas. There
were 681 attendees, and I fielded live questions from many of them (by
myself), and somehow I got through it, but not without much pain and
anxiety.
So, I began leveraging my situation as best I could, basically by
"leaving" instead of by sticking around to be
embarrassed about all the things that I didn't know and couldn't do. Although I
couldn't justify international travel, I did keep the airways busy
every week, mostly to Austin (where most of my team members were) and
Rochester, MN (where the software was being developed). I also attended all
of the seminars I could (like useless Java One road shows in San
Francisco, and marketing events in Las Vegas), just to get out of the
office.
(back
to the Table of Contents)
So, what had gone wrong? Well, there's an old axiom called
"The Peter Principle," but I had never taken it seriously until looking back at this point in time.
It says that one tends to get promoted to his level of
incompetence. In other words, we all have limitations in what
we can do, but we keep striving for promotions. We become so
good at getting those promotions that we suddenly find ourselves promoted to a
level where we can no longer perform our job duties. We rise to the level of our incompetence.
At about this time, I had a friend who worked for the Post Office.
Like myself, he was detail-oriented and technical, but he
received a promotion to a management position. After just a
few days in the job, he asked for his old job back, and they chose someone
else to take his management position. Now, this is probably
what I should have done that first day in the late 1980s when I was approached
about being a team leader. I should have said, "No, please
just let me stay in my technical job that I enjoy. In fact, you
can take back my latest promotion to the Advisory level, and the salary
increase, and I'll just be a Staff programmer for the rest of my life."
However, I was not as wise as my friend.
I learned an important lesson through all of this. Employers and
employees do not put enough emphasis on making sure that each employee
likes his job and looks forward to coming to work every day.
Although change is inevitable, not enough is said about the
gratification that the employee receives when he stable
and contributing at a high level. He's not worrying about
his job, his work is challenging, and he is happy. Instead, employers are
constantly looking for "new opportunities for growth and learning" for
the employee, as well as "preparing" him for his next promotion by
pushing him out of his (productive) comfort zone.
My pet peeve is an employer who insists on change even when the
employee is stable, happy, and getting good performance
reviews for a few years. Instead of letting him keep using the
expertise that he has built up in the last few years, his employer
wants to change everything (which usually means adding more recurring meetings you his calendar).
For example, instead of letting an
"individual contributor" do the things he does best, his employer
insists that he take on more leadership roles. This often ends up
with the employee having
to learn a new set of skills instead of continuing to utilize the
skills that he has built up in his current job. This, in turn,
finds the employee doing things that he doesn't enjoy and that
he's not good at, which ends up hindering his own performance and his
team's productivity. I'm all for
learning new things and new challenges, especially in the ever-changing
high-tech world.
However, employers should understand that it's best for the
employee, as well as the company, to keep employees productive, happy,
and doing what they do best.
(back to the Table of Contents)
So, I left IBM on July 17th, 2001 after 24-and-a-half years of service.
(However, I'll always be an IBMer at heart.) I accepted a partial pension and a generous
severance package. I was indeed fortunate to start collecting
this pension because IBM terminated its retirement program in 2007.
But, you can't retire on a partial pension, so
what do you do? My answer was: You have no other
choice. You haven't reached
your goals, so set new ones, maybe with lower expectations, which
is the best you can do. What about just enjoying
your work? You pull yourself up by your own bootstraps
and start fresh; i.e., maybe at a lower level. I
was 45 years old, didn't have a job, and didn't know how to look for one. So, I
started learning.
(back to the Table of Contents)
First, I had to prepare a resume. Come to think of it, this
was the first time in my life that I had ever really needed a
resume of my IT background. I had always maintained an internal resume within
IBM, but I had never sent an external resume to
anybody.
(back to the Table of Contents)
Toward the end of the last century, my focus (as well as that of most
other software engineers) turned to the internet. I had started
using personal computers in the early 1980s, but most of my training was on
my own--not from IBM. I started using
Microsoft Windows in about 1990. It was the old 3.0 version that
the user had to initiate from DOS. I first used the Internet
(World Wide Web) in the early 1990s, using Internet service
providers AOL and Verizon (Southwestern Bell / AT&T). This
was a slow and laborious process, using a 32 bps dial-in modem, and either no browser
at all or primitive browsers
like Mosaic and NetScape. At that speed, downloads took forever,
even to populate the first web page. I would set the browser to
not download images so that the pages would load more quickly.
I soon learned that the Internet is a global system of interconnected
computer networks that use the TCP/IP (Transmission Control Protocol /
Internet Protocol) protocols for connectivity; HTTP (Hypertext
Transfer Protocol) and HTML (HyperText Markup Language) for Web
browsers; and, FTP (File Transfer Protocol) for uploading content.
I learned enough about it to build my own website, and I was
always an avid student of the Bible. So, I built my website,
Christian Data Resources, on the verizon.com domain in 1997 where I published articles on Bible
study and answered Bible questions from visitors. In 2008, I purchased my own
domain name and transferred my website to http://www.christiandataresources.com. There are a lot of sites that enable the user to build
a website, on their domain. However, in order to build a site
from scratch on my own domain, I had to learn about:
- Domain names - I got mine from GoDaddy.com.
- Web hosting - Again, I used GoDaddy.com, for convenience.
- HTML - I built all of my pages by hand with a text editor, or with a
simple page editor (NVU). This included HTML Title, Meta, and
Keyword tags, in order to be recognized by search engines, as well as
linking structure (internal and external).
- FTP (File Transfer Protocol) - For uploading files to the site.
- Google Webmaster Tools - To let Google know about the
site and to guard against cloaking, spamming, hidden text, link
farming, etc.
- Submitting links to search engines
- Continually adding content
- Wordpress - I use it for a blog.
- Backlinks - This is trying to get other (hopefully popular) sites to link back to the new site.
- Search Engine Optimization (SEO) - Tricks to make the site rank higher in search engines.
- Google Adwords - Pay-Per-Click (PPC) online
advertising for the site. Actually, I ended up using Bing Ads
because they're cheaper.
- AdSense - This is trying to make money by posting ads
for other sites. I have since discontinued this because it seemed
counter-productive due to the nature of my site. I like for
everything to be free, with no ads, etc.
- Google Analytics - To track site traffic, downloads, etc.
- (Later) Mobile-Friendly Websites - To make my pages device-friendly, etc.
(back to the Table of Contents)
I sent my resume (with the appropriate letters and applications) to
about 150 companies. Then I started driving around the city
where I lived (Coppell, TX), finding large and small businesses and
knocking on doors. One day I saw a "Now Hiring" sign in a
strip center. I carried my resume in and
inquired. I found out that the company was called HNC, a
small (and private) medical (Worker's Compensation and Auto) bill
review company (although I didn't know what that meant) with about 1,000
employees. (HNC would later be bought by Fair Isaac, and
eventually by Mitchell, International.) The HR rep seemed
impressed with my resume, and she quickly got me two interviews. Within a week, they called
me with an offer to be their EDI Coordinator. Again, I didn't
have a clue what this meant--just something related
to IT. They offered a starting salary that was only about 40% of what I was
making at IBM when I left. After some negotiation, I accepted the
job, but I was still making less than half of what I made at IBM.
So, I had found both jobs in my career (with IBM and with HNC) without
the benefit of nepotism. Although there is much value in
networking (in which I have very few skills), I had always been proud
that I was able to find my jobs simply by approaching strangers in
companies where I had no inside contacts.
(back to the Table of Contents)
I began my new job on September 10th, 2001 (yes,
the day before 9/11). I remember taking a trip to St. Louis
within the first couple of weeks because we were transferring an office
from there, and the current (leaving) EDI coordinator worked
there. Due to 9/11, there were hardly any other air travelers
in the airports or on the planes.
Here's how medical bill reviewing works: Bill review
companies or insurance companies bought or leased our SmartAdvisor software
(named CompAdvisor at the time), or they hired us to do their medical
bill review for them, for their Worker's Compensation and/or Auto
claims. Insurance companies sent in their claims
and related bills. The SmartAdvisor software applied all
appropriate fees/discounts according to each jurisdiction (state laws),
PPOs, etc., and it returned an Explanation of Review (EOR)
or Explanation of Bill (EOB) to the insurance company. In some
cases, the bill review company also handled invoicing and payments
to providers (doctors, hospitals, etc.) Most claims and bills
were automatically scanned into the system, and many bills were processed
completely automatically by SmartAdvisor. In some cases,
pended bills, or audited bills, needed manual attention from a bill
review specialist or a nurse. In return for our software
and/or services, our company received
a fee for each bill reviewed, or an amount for the sale or lease of
SmartAdvisor.
At the end of each day, data was exchanged between our company and the
insurance companies through a process called EDI (Electronic Data
Interchange), via FTP processes. For us, this included
importing (receiving) claim files and bill files with the latest
information, and exporting (sending) payment files to the insurance
companies. In addition, imports and exports were also required
for each individual PPO.
My new job with HNC was to coordinate these imports and
exports. The intent was that I would initiate these jobs in
the evenings and they would run automatically overnight.
However, there were a lot of caveats (shortcomings in the software,
etc.), so I often needed to write Java programs to fix mistakes, add or
subtract fee amounts, etc. In addition, I created automation
programs to launch the EDIs automatically. I excelled at this
job, and received above average performance evaluations.
(back to the Table of Contents)
In 2002, Fair Isaac bought our small company, but my day-to-day duties
remained basically the same. I enjoyed the challenge, but I
often worked long hours, well into the evenings and nights, probably 60
to 80 hours per week. In
2005, I transferred into the Quality Assurance department for testing
SmartAdvisor software. The SmartAdvisor development
organizations were based in Irvine, CA, so I made a couple of trips
to Irvine. I was now (finally) back into the area that I
loved--software testing. In 2006, I had another stroke of
luck. We developed a new product called SmartReports, and I
became the primary person for testing SmartReports. This was
exactly what I loved doing. SmartReports generates reports
from the SmartAdvisor SQL databases using the same relational database SQL
query language that I had used some 25 years earlier on the IBM ADF
project. I loved testing the reports and comparing the results
to SQL queries against the databases. I created defects as
necessary, then tested the defect fixes. As the last group to
touch the software before each release, QA is ultimately responsible
for customer satisfaction with the quality of our products. I
took pride in my work and I believe that I was very effective at
it.
In 2003, I began suffering from cold and painful hands whenever I used
the computer. I was diagnosed with Raynaud's Syndrome, and I
had to cut back to part-time for a couple of years. However, for
the past ten years, I've been working full-time again, controlling the
Raynaud's by wearing gloves while I work, by limiting my time
on the computer, and with medication.
(back
to the Table of Contents)
On February 1, 2003, we lost the space shuttle Columbia on its 28th
mission (STS-107) resulting in the deaths of all seven crew members.
This was the space shuttle that I had programmed for in 1981.
It was almost home, already in the descent phase, and again I
could envision the maneuvers of the ailerons and rudder as it was
preparing to land. The space shuttle program ended with the
last flight of the shuttle Atlantis, STS-135, on July 8, 2011.
Every time one on those 135 missions ensued, I wonder how much of
my software code was still being used for navigation and flight control.
(back to the Table of Contents)
In 2008, Mitchell International bought our SmartAdvisor division from
Fair Isaac. SmartAdvisor was a better fit into the Mitchell
organization, and we were growing and thriving there. In 2011,
I had my 10th anniversary with Mitchell (/ Fair Isaac /
HNC). Although I had worked for three different companies, I
stayed basically in the same place for these ten years. In
2008, I began working from home every day, and I enjoyed this perk
tremendously. Travel for Mitchell included trips to Irvine,
CA, and a trip to San Diego for a software development seminar.
In April, 2012, Mitchell converted their software development
methodology from "Waterfall" to "Agile," like most companies were doing. (I had
been used to the Waterfall approach where the Business Analysts (BAs) prepared specification
documents from which to test.) The adjustment was awful.
I called it DSP (Developing by the Seat of your Pants). There
was no documentation, but there were plenty of meetings every week:
- 5 Daily stand-up
meetings
- supposed to be 15 minutes each, but really 30 minutes to an hour (5 hours)
- Story grooming meetings - basically watching the product owner type (2 hours)
- Release planning meetings (4 hours)
- Sprint planning meetings (2 hours)
- Sprint retrospective meetings (2 hours)
- Demo preparation meetings (4 hours)
- Demo meetings--for all scrum teams
(4 hours)
- etc.
The demos were a lot of trouble, showing what we
had built to an indifferent audience. And the daily stand-up
meetings drove me crazy.
We were supposed to stand up, tell what we did yesterday,
tell what we were going to do today, and list any roadblocks we had.
It was like I was in grade school again. It made me
so nervous that I had to rehearse what I would say. I often
wanted to say, "Yesterday I went to meetings, today I will go to meetings, and
my roadblock is too many meetings."
Sometimes I had eight or nine meetings per day. I found that
instead of working 40 hours per week, I was working 55-to-60
hours in order to accommodate the extra 15-to-25 hours of meetings. I
know to never say "never," but I will do my best to never put myself in that
situation again. Of course, some meetings are really necessary,
but in general I don't particularly like meetings, mainly because
most are not necessary. I don't like the
boredom of the meetings and I don't like having the attention of the
group focused on me (because of my fear of embarrassment, etc.).
I'm a software tester--not a meeting attender.
(back to the Table of Contents)
So, after suffering through a few iterations of two-week sprints, I felt
desperate to find another job. I left Mitchell on June 29th,
2012, and I joined Brink's, Inc. as a QA software engineer on July 1st,
2012. They had tried Agile and they had decided to go back to
Waterfall. I had fun testing and I felt productive for about a year-and-a-half,
mostly testing CompuSafe (intelligent safe) software. Then
a new sheriff came to town in the form of a QA director. He
basically brought all of his own people in (dozens), and tried to run
the existing team off by making life miserable for us. He was
successful, as nobody wanted to work for him anyway.
One-by-one we started peeling off.
(back to the Table of Contents)
I had several interviews with Thomson Reuters until the QA manager
confided in me that he was leaving the company. My only other
lead was through a former QA person at Brink's, Manjula Muniyappa.
Her husband, Santosh Ramakrishna,
was a development manager and he had recently moved to a startup company
called HealthSparq, a subsidiary of Cambia Health Solutions.
They were developing software to inform and empower health care consumers
through an online shopping experience that helps them understand their options,
make better choices, and learn more about the advanced solutions
for health plans and employers. They're based in Portland, OR, but
due to an acquisition, they now had an office in Lewisville, TX.
I had a phone interview with Randy Pellegrini, the QA manager in
Portland, and then an additional interview with Santosh and team members at
their new location in Lewisville.
The job was the team leader of a one-person QA team. It sounded like a
match except that they used Agile. However, they convinced me that
their Agile approach had been honed down to be more efficient and have
less meetings. I took the job, partly because I looked
forward to it, and partly because I was so miserable at Brink's.
My last day with Brink's was on October 3rd, 2014, and I
started with HealthSparq on October 6th, 2014 as a senior quality analyst.
My first month there was rough. The learning curve
was steep and the onboarding process was lacking. Furthermore, my
father-in-law went into the hospital on October 13th, spent three weeks
in the hospital and a nursing home, and died on October 31st.
My new job included testing web services (APIs) which I knew nothing
about. Finally, Tomomi Ioffe, one of the QA people in
Portland, tutored me for an hour or so, and I was on track. I learned a lot, I
enjoyed my work, and I got to work from home two days per week. I
even adjusted to the Agile way of doing things. I still had some
days with eight or nine meetings, but they became fewer and further between.
And, I still rehearsed what I'm going to say at the daily stand-up
meetings, as well as the demos. However, the adjustment to Agile was easier for me
at HealthSparq than it had been at
Mitchell. I think this was because I was getting in on the ground
floor of a brand new product: the Admin Console.
By 2018, technology was changing again. This time it was to automation,
with Behavior Driven Design (BDD), Test Driven Design (TDD), Cucumber
scenarios, and step definitions in the Ruby programming language.
Automation was one of the reasons I left Brink's, and it would play a part
in my leaving HealthSparq as well.
Automation meant that HealthSparq changed my job role form Quality Analyst (QA)
to Quality Engineer (QE). It doesn't sound like a big change, but the
new technology was a major change that would take years to master. I was
63 years old and I could collect Social Security, so, on August 3rd, 2018,
I retired, after 42 years as a software engineer.
(back to the Table of Contents)
Software Patents
During the early 1990s, I became heavily involved in writing
software inventions and patents for IBM. IBM provided
financial incentives for employees to come forward with new ideas,
although, according to an agreement when I was hired, IBM was the owner
of all resulting inventions and patents (Re. revenue, etc.). I was just the
inventor / author. I had a lot of new ideas, and I
had some 300 articles published in IBM Technical Disclosure
Bulletins. In addition, I had the following ten patents granted by the U.S. Patent
Office:
Patent
Number Title
- 5,600,828 File specification wildcard (First Invention)
- 5,664,063 Automatic user notification of certain meeting attributes
- 5,682,475 Method and system for variable password access
- 5,694,616 Method and system for prioritization of email items by selectively ...
- 5,761,420 Method and apparatus for telephone proof of documents
- 5,787,231 Method and system for improving pronunciation in a voice control system
- 5,878,230 System for email messages wherein the sender designates ...
- 6,230,121 Measurement and validation of interaction and communication
- 6,321,378 Automated code replication during application development
- 7,155,493 Method and apparatus for improved internet navigation (Patent)
You can view these only by searching at
https://patents.google.com/advanced for Inventor Name
= "Owen W. Weber" (https://patents.google.com/?inventor=Owen+W.+Weber).
(back
to the Table of Contents)
Throughout my years as a software engineer, I earned the following
certifications:
- 1997, IBM Certified Professional, Integration and Test Specialist,
IBM
- 1998, Certified Java Programmer, Sun Microsystems (Java_Certification)
- 1999, WebSphere Application Development Certification, IBM
- 2008, Certified Software Tester (CSTE), The Quality Assurance Institute (QAI)
- 2010, Re-certification as a CSTE (through 2014), QAI
(back
to the Table of Contents)
Changes
What changes have I seen? The changes in technology have been unreal.
As I mentioned, from 8K of memory on the slow computer that ran
my whole college 40 years ago, to 8B of memory on a laptop or a phone
today.
Office attire has changed from a dark suit, white shirt, and tie every day to shorts, tank tops, and flip-flops.
Plus, working from home is a great perk.
(back
to the Table of Contents)
Goals
So, where am I on achieving my goals?
- I fulfilled a childhood dream of working on the space program.
- I made the Advisory level with IBM after just eight years.
- At one point, I attained the private office that I had always wanted,
only to give it up when times got lean at IBM, working instead in tiny
cubicles, or in large "bull pens" with 25 other people. I never had a private office again
until I started working from home. Maybe that's why I like working from home so much.
- I wanted to be a member of IBM's Quarter Century Club, but I fell
short of that by only six months.
- I wanted to retire from IBM with full benefits after
30 years of service, but I fell short of that goal by five-and-a-half
years.
- Instead, I retired on August 3rd, 2018.
Outside of my career, I traveled to Hyderabad, India in 2000 for a Gospel Crusade, where I preached three times a day, having never preached before in my life.
I also maintain a website: https://www.christiandataresources.com, where I write Christian articles and answer readers' questions.
Owen Weber 2018 |
|
