By Jim Grey (about)
Indulge me today as I tell a story. It’s a long one, so strap in.
My 33rd anniversary in the software industry was the Sunday that just passed, July 3. I remember the date because my second day on the job was a paid holiday!
I want to show you just how far our industry has come and how much we’ve learned.
The first software company I worked for was Applied Computing Devices in Terre Haute, Indiana. That place was filled with wicked smart people, and it was a joy to work with them. We made software that managed telephone networks. Our customers were AT&T; US Sprint (now called just Sprint); GTE (now Verizon); and several Regional Bell Operating Companies (landline phone companies) including Ameritech (which served Indiana), BellSouth, and Pacific Bell. These companies provided primarily landline (“wireline” in the biz) telephone service then but some were beginning to branch into mobile service. This was complicated stuff to manage, and our software products were correspondingly complex. I needed my 400-level college mathematics classes to understand some elements of our software.
I wasn’t a software engineer – I was a technical writer. I wrote huge paper manuals we shipped to customers that explained to them how to install, configure, and use our software. The software industry was very small then, and as I graduated with my Math/CS degree the economy was in a downturn. I wasn’t getting many interviews for coding jobs and the interviews I did get didn’t lead to offers.
I lived on campus that summer while I looked for work, but the summer would soon end and I’d have to go home and live with Dad. I had zero interest in doing that, so I decided to pivot to just getting any job at a software company – QA, support, IT, janitor, anything. I’d figure out my way from there.
A professor at my school knew people at ACD and introduced me. They needed a technical writer. I said I’d happily do the job, and they hired me at $23,000 a year (about $54,000 today). To my astonishment I discovered that I loved to write, even more than I enjoyed writing code. I became very good at explaining that deeply technical software to users.
What I really want to tell you about is what working there was like, aside from being in awe of my super smart co-workers. The software industry was very different then!
Finally, software subscriptions were not a thing yet. Companies paid for software entirely up front and got to use the release they bought forever. They had to pay again for major upgrades. Some smart companies spread their payments out over a period of years, but the license was still perpetual.
When you mailed customers the new version of your product most of them wouldn’t install it right away and some would never install it. “The version we’re on works just fine for us.” It was a nightmare in support. We finally decided to support only the last four versions, to our customers’ extreme frustration but the support team’s undying gratitude.
The best SDLC available was waterfall with all of its problems that were not lost on us even then. The whole industry did very long release projects, such as two months of requirements gathering and design specification followed by nine months of coding and then three months of testing. Even if we did see then (and we mostly didn’t) that small, frequent releases were better in a whole bunch of ways, we couldn’t really do it. It was expensive to ship on physical media, and disruptive to our customers to have to do frequent installs.
We thought back then that software development projects should be managed like manufacturing or construction projects. That led us to create enormous Gantt charts (printed dot matrix) that we’d tack onto a huge wall, and use them to track plans and work completed. It never failed that during the first week of coding we’d discover something that we didn’t think of in the design phase, and we’d have to replan the entire project and print all new Gantt charts. We did this over and over every project.
When the code finally reached QA, the testers would find hundreds or thousands of bugs. They had hardly seen the software before it reached them, and were only barely involved during the construction phase. Because of sheer bug volume, the test phase always needed to go way longer than planned. But by then we’d promised a delivery date to customers. So we could hit the promised date, every release went out with a whole bunch of known bugs that we’d fix in what we called a “fast follower” release several weeks later. Smart customers learned not to install the release until the “fast follower” was available.
Because of all this, projects always turned into awful death marches with lots of late nights and weekends in the weeks leading up to the release date. Burnout was high. But few people quit over it because we thought it was just how it had to be. There weren’t many other software companies to defect to anyway, and the ones that existed had death marches too.
ACD’s tech stack (which was a term we didn’t have then) was C++ on two flavors of UNIX: Digital Equipment Corporation’s Ultrix and IBM’s AIX. Our software ran on DEC and IBM RISC-based minicomputers, machines that were about the size of a bar fridge. We had a whole bunch of them in a big, cold server room. Because we were on the outskirts of Terre Haute our power was supplied by a rural power cooperative and wasn’t terribly reliable. I don’t know why we didn’t have uninterruptible power supplies or a generator, but we didn’t. About once a month we had a short power outage. The minicomputers were chained in sequence and had to boot in order. It took about 10 minutes for one machine to boot. It took more than three hours for all of the computers to finish booting. If the power flickered after about 2 pm, we all just went home for the day.
There was no working from home. The minicomputers were available only on the in-office network. I think it was not technically impossible to connect them to the Internet, but at home we all had only dialup access. Not only would speed have been a concern, but the family wouldn’t enjoy having the phone tied up for hours while you worked.
Everyone had a terminal on their desk on which they did everything. At first all engineers used the venerable VT100 terminal, but later they bought them all these huge $2,000 graphics terminals so they could build the UI in X Windows. UX design wasn’t a thing yet. For that matter, neither was the distinction between front end and back end engineering. Our software engineers designed our user interface, and most of them weren’t good at it.
As a technical writer, I had a Macintosh II computer on my desk running System 6. (System is what MacOS used to be called.) It had 8 MB of RAM. That was a screaming machine in its day. I wrote manuals in a program called Interleaf. I used a terminal emulator on the Mac to connect to the minicomputers.
There was a holy war over text editors. IDEs weren’t a thing yet, so we all coded in a text editor. I was firmly in the Emacs camp, but most of my co-workers loved vi.
Our terminals were on a token-ring network linked back to those minicomputers. Token-ring networks don’t function unless the chain of nodes on it is complete, as information flowed through every node on its way around the network. I did not know this the day I decided to rearrange my cubicle. When I unplugged my terminal to move it, I took half of the network down. I was not anyone’s favorite person that day.
AIX and Ultrix and their underlying hardware were different enough that our code was a mess of IF AIX and IF ULTRIX statements. Sometimes we had to write separate AIX and Ultrix versions of entire subroutines and functions. We had to compile the code twice, once on AIX and once on Ultrix! Java was a total game changer when it came out in 1995. You mean we can write one codebase with no OS- or hardware-dependent IFs and no separate routines, and run it on any machine that can run the JVM? Voodoo!
The software industry was a far less diverse place then. The strong majority of engineers were men, largely white, most of them younger than 35. Two of our engineering managers were women, I recall. We did have a few engineers who immigrated from elsewhere. There were no people of color. It was not safe to be out at work (or anywhere, really) then. I knew that one of the technical writers on my team was gay, but that’s only because we’d become friends and he decided to take the risk and come out to me.
The software engineering team had two titles: Software Engineer and Senior Software Engineer. This was typical in the industry. You had to have at least 10 years of experience, but more likely 15 years, as a Software Engineer before being considered for promotion to Senior. The bar was higher for Senior then, too. I’d say a Senior engineer back then was skilled and experienced more like a Staff or Principal engineer today.
I was very happy at ACD. I loved working there. Because there were only so many telephone companies then, however, we had maybe a dozen customers. Our relationship with US Sprint was always iffy, and one day we pissed them off one time too many and they canceled their contract and dared us to sue them over it. The loss of that revenue crippled us, and was the beginning of the end for ACD. The company started to circle the drain. I did not want to be unemployed in Terre Haute, so I took a job in Indianapolis and moved. Then as now, most Indiana software development happened in Indianapolis.
Let me tell you one last story from ACD, and it involves US Sprint. They were angry with us over one too many buggy releases. They sent us a list of all of the bugs they wanted fixed, and they wanted them fixed by Monday or they would buy a competitor’s product and move on from us. The Engineering team worked days and nights trying to fix those bugs. They worked into the weekend, but by Sunday morning they still had not licked a couple of particularly thorny bugs.
Remember that we had to ship code on physical media. We used tape cartridges, which were smaller than a VHS tape but way bigger than an audio cassette tape.
The Federal Express deadline was approaching on Sunday and the engineers still weren’t done. (Federal Express wouldn’t be renamed to FedEx for many years yet.) Then someone had a brilliant idea: we would ship US Sprint a blank tape with our usual letter listing the changes in the release. And so we did.
Monday we got a call from US Sprint: no matter what they tried, they were unable to load the software from the tape we sent them. Support was prepared: “Oh! We are so sorry. We can’t imagine what must have gone wrong! We will send you another tape today.”
By that time the engineers had fixed those last two bugs. We wrote the actual maintenance release to a new tape and sent it to US Sprint. The company lived to fight another day!
36 replies on “Working in the software industry, circa 1989”
What memories of those early days! I interviewed with them too. No offer. 😦
I probably wouldn’t have gotten an offer either if I had applied to be a software engineer. It was because I was open to whatever and was willing to take whatever pay that there was a match!
Oh yay, the “but it worked on my machine” excuse, but on enterprise level.
Played that card once or twice on floppy disks at high school 😛
I know (knew probably is a better term nowadays) Pascal too. Thanks for sharing Jim!
It was fun to put together all of these memories!
My first tech writing job in Indy was for a company that produced industrial catalogs. Most of their customers were low-tech and liked having catalogs the size of phone books. If some of them were really tech-savvy, though, we could publish it for them on CD-ROM.
On a side note, a phone book arrived at our house this week. It went promptly into the recycling bin. Time marches on.
I think I know the company. It’s fascinating how the tech writing job has changed over the last 30 years or so.
“When the code finally reached QA, the testers would FIND hundreds or thousands of bugs.”
Fixed, thanks. I meant “write hundreds or thousands of bug reports.”
I started about 4 years later – I remember seeing piles of floppy disks for each release. Did you have to wear a tie to work? I remember we did, and I think that was pretty common.
Ties were not required where I worked. Jeans were frowned upon but not banned. I wore slacks every day, dress shirts in the winter and polos in the summer.
I was actually in Terre Haute a few years later. I worked in the data center for Terre Haute First National Bank.
We were a mainframe shop and wrote reams of COBOL. We were a little more diverse– we had several ladies in the shop and an African-American male also. We worked hard for the bank and had a lot of fun.
Core systems! The backbone of banks and government even today! I was a First customer during my time in TH.
[…] ทำงานในอุตสาหกรรมซอฟต์แวร์ ประมาณป… (ความคิดเห็น) […]
Graduated Math/CS 86, officially in 35th year of software developer, still going I just don’t know how we actually developed anything, lol. I do remember a contract with Isotro (which was bought by Bay Networks and then Nortel networks) where we had to support C++ over HPUX, Solaris (slow-larus) and Windows. Learned all about the differences in template classes by platform…
Thanks for sharing!
Glad you enjoyed it! We got it done by brute force sometimes, that’s for sure.
[…] Работа в индустрии программного обеспечения, около 1989 … (Комментарии) […]
Amazing read. The blank tape solution was genious! Thank you for sharing.
It got us through that crisis with US Sprint, but it only kicked the can down the road. They remained displeased with us and in the end left us.
[…] https://dev.jimgrey.net/2022/07/05/working-in-the-software-industry-circa-1989/ […]
Wow. I graduated 1988 and at that time C++ was still C-Front (as far as I remember) and was a pre-processor. g++ won’t come about for quite a while longer. We were all writing C, and embarrassed to let people know that we wrote some Pascal (Turbo Pascal ruled at that time) as well. And Ultrix! What a fond memory trying to identify all the subtle differences it has with BSD.
You are dredging up dim memories for me – it’s crazy how much stuff I’ve forgotten about!
“Our software engineers designed our user interface, and most of them weren’t good at it.”
They’re still not — engineers should not design user interfaces.
“…but most of my co-workers loved vi.”
Because they were on the side of Truth and Right. 😀
The nostalgic look at a simpler time was nice… I don’t have near the experience in the industry you have, but I’ve become horrified at how — seemingly overnight — this area of technology has become this iron-fisted juggernaut dictator on all aspects of life. One day, I was just ditty-boppin’ along learning code and the next I stand in disapproval at how it’s being used against us.
Draw swords, good sir: we will duel to the death over Emacs vs. vi! 😉
It was lovely when the software industry and the Internet were places of optimism and good things. I agree, it’s a shame how it’s been used to control and manipulate us.
LikeLiked by 1 person
Haha… Indeed we will. Have at you!
Based on your relationship with all the bell’s, you might get a kick out of the old Colbert video about AT&T…
[video src="https://heyaaron.com/junk/colbert-report-roasts-att-cingular.mp4" /]
LikeLiked by 1 person
Jim let me know when he had left ACD and suggested I might interview as a tech writer there. I was working as the lone software developer at a small computer consulting company, and it wasn’t a great situation, so I really appreciated the tip (and I am still grateful). I did not know Interleaf but knew FrameMaker, Ventura Publisher, and several other DTP packages. I interviewed and got the position …and never wrote a single piece of documentation.
On my first day, it was noted that I had SQL and unix experience listed on my resume, along with C, Pascal, and a few other languages. Jim mentions delivery dates being promised while there was still a raft of bugs — in this case, delivery dates were promised a few months down the road and there was no staff on the project yet — at all. I was put onto this project and given the statement of work to read through and documentation of the system we were replacing. I was to get to work designing the database schema to support the new system. A contractor was being hired as project lead and would arrive the following week. A couple of days later I was given a word processing document he’d composed with a draft of some data structures. I saved it as plain text, wrote an AWK script to process the text into DDL, and used this to build the first iteration of our schema. I was a developer from that point forward.
I worked there until ACD went under — my last day was the day the new owners came in to take over the company. My first daughter had been born a couple of months before on the very day ACD declared bankruptcy and laid off hundreds (September 15, 1995). I learned the news from a co-worker that evening. My wife and I signed for a house loan the following day, and the loan officer recommended I find another job even though I still had one. The project I was on was one of the only ones still bringing in money – too many eggs in one basket when they ticked off another big customer on one of the projects and that customer decided not to pay for any others. I really thought highly of everyone I was working with there and didn’t want to leave with this project dangling, so gave two months notice to leave time to finish our delivery. Luckily, my new employer, Rose-Hulman, was willing to wait.
Like Jim says, the place was full of a lot of very smart people, and I really enjoyed working there. After five years at Rose-Hulman, I came back to another iteration of a smaller group of the same people still working together, selling a web-based version of one of ACD’s earlier pieces of software. A few years later, I landed in Indianapolis too after subsequent owners shut down the location in Terre Haute and offered only a few of us jobs elsewhere. There are still a handful of us old ACD-ers left, though it has dwindled in recent years. That old, formerly ACD product is still in production use but has long since seen its heyday.
I think the people and technology there were in some ways second to none, but commitments were ultimately mismanaged and people overextended. It was good while it lasted. Thanks for the story, Jim.
Robert! Good to see you here, and thanks for telling the story of the company after I left. There was so much raw potential at ACD, but we weren’t good at setting realistic expectations with customers and then living up to them. It was always grand promises — checks that Engineering didn’t write but had to cash.
As soon as I saw the title of your article, I immediately thought of the holiday bacchanals that my first 2 companies threw in the early and mid 90s. I have a lot of stories about my work in what was then very early UI design (entire products designed in MS Paint on Windows 3.0? Yikes). But the parties… today it’s strange to remember that they actually happened.
2 of the best:
Borland rented a very large space with multiple open bars and a spread that rivaled the buffet at the Bellagio in Vegas. Live music, a raffle with multi-thousand-dollar prizes, and I’m sure that I’m forgetting a few things.
Oracle rented hundreds of rooms at the Fairmont, Mark Hopkins, and Stanford Court hotels in San Francisco. All food and drinks at the 3 hotels were comped IIRC. Formal dress was required, which actually made the whole event that much more fun. Live bands and dances in multiple conference rooms. It’s been close to 30 years and I still remember the rack of lamb I had at the Stanford’s restaurant, the outstanding drinks from the Fairmont’s Tiki bar, and watching Larry Ellison get pissed off at losing a pinball game.
Those were the days.
You worked for companies with real money! What an experience you had.
At ACD, the best we got was “watering the horses.” The company owned two horse troughs which every now and again they’d fill with ice and beer, and we’d all knock off at 3 and sit on the back patio and drink together.
[…] View Reddit by speckz – View Source […]
[…] My first job in Tech wasn’t until (until?!?) 1993. But I could still relate to this article on Working in the software industry, circa 1989. […]
Hi Jim, great post. If I remember correctly, you and I had a joint going away lunch! ACD was an amazing company, and as you said full of smart people, including the CEO. Bill was always knowledgeable about the technical side of things.
The company basically had to invent a software management paradigm from nothing; there was no github, no branching of versioned code, no merging of different code sets. All done with brute force. Looking back, it almost seems impossible that we were able to develop such complex systems. And that’s not even including the hardware! (remember udc, fep, etc)
Dave! Nice to hear from you. I had forgotten all about our farewell lunch until you mentioned it! Thanks for opening the door on that memory.
It’s incredible what ACD built given the stone-age tools.
I wrote the FEP manual! It was the one I was most proud of. I so wish I had taken a copy with me when I left.
Well – I think there were a few more females than you remember, lol, me being one of them (i think four on the programming side -and a technical writer and a project manager – still pushing the software thru with both the Roberts at the new place) We also had some contract programmers that were Russian, Indian, Vietnamese, etc. I personally felt, for the times, we were forward thinking. Jeans might have been frowned upon for you guys upstairs, but we wore them all the time unless customers were in house. There was a tree planted for one of the Indiana programmers. (I think) over at ICTT, tragically gone now with the new highway. (at least i think so)
I was one of the few left after that fateful September. I loved it there.I cleared the layoff because I could configure those monsters. But took a job elsewhere a few months later before the end of the end.
Thanks for the trip down memory lane – ACD was definitely ahead of it’s time.
Oh my gosh, Charla! It’s nice to hear from you.
My memories have clearly gotten a little twisted up over these years. I thought you were a test engineer. I had forgotten about the immigrants we had on the team. I do remember Betsy and Jeanne as managers and now that you bring it up I remember Khanh of course. I’ve updated the text to better reflect that.
When I started at ACD in Training & Documentation I was in the “Network Knowledge Center” across the street, and I only saw jeans over there on Friday. When the Doc team moved under Engineering we came to the main building and I saw that peoples’ clothing choices were more relaxed.
I drove out by the old buildings a year or so ago and saw no sign of the old ICTT/Network Knowledge Center building. I remember while we worked there, that plans for what became 641 were on the books and even then the new road was planned to take out that building.
I just loved it at ACD and was sad and a little distraught when it became clear to me that the company might not make it. With my skillset I didn’t want to be unemployed in Terre Haute, so I got a job in Indy and moved. I was single and a renter, so it was easy enough for me to do that.