| Home Blogs | Copyright 2017, Randy Strauss |
(Note: Jump to the end if you're interested in my patent.)
Work was engaging, and often challenging, but at the same time, a bit boring. There were rarely interesting problems. Occasionally someone would talk about a puzzle, and it was fun to solve them.
One day we talked about our bug database. Assigning bugs to developers was a pain. Someone had to go through them and figure out the best person. Some groups assigned bugs by feature, some by area (UI vs core vs graphics), some by platform (we supported many different kinds of Unix systems, and some by version- some people would look at a bug in a feature no matter what version of our software it occurred in, and some had a single person to support each old version.
The managers wanted to somehow automate assignment, but the groups just did things too differently. The IT department said they could build a single rule for the database, but not 4 different ones. And somehow it would have to be changable, since versions changed, features would be added and engineers would leave and new ones would be hired. By the time I heard about it, people had given up.
I had never worked with databases, but it seemed to be a simple combinatoric problem. There were basically 5 independent variables, platform and OS(10), product(4), version(3'ish), feature(20), and area(5), and one dependent variable, the assignee. So we just needed a way to specify all the tuples. And we had FrameMaker.
It seemed to me like it shouldn't be too hard, so I volunteered to create a solution.
Pretty quickly, it seemed like it shouldn't be too hard to put the data into tables. We could keep the assignments in a single document in tables, edit the tables when we needed a change, then run a program to generate the tuples and IT could load them into the database.
I think this was in the days before FrameMaker had an API. But we could save a file in a text-format. So I just needed to figure out what would go into the document, and how to parse it after it was saved and generate the tuples.
The design seemed pretty obvious. Every tuple had 6 fields. A table had two dimensions and the assignment. So before a table could determine assignments, 3 other fields needed to be determined.
So the document contained statements like platform=something or version=something, and the "something" could be "*", meaning all. And then a table title would say what kinds of values the rows and columns described.
Since "*" meant "all", there would have to be 5 tables that listed all the acceptable values for each field. This would also allow us to catch spelling mistakes. I added a 6th table for all the assignee's names, so those could be checked.
Finally I needed to parse the output. I had never had a compiler course, but I had heard about Lex and Yacc and I suspected they'd be useful.
They were. This was still in the days before the internet, I think, so I just read their man pages and figured out how to use them.
The whole project took about 3 weeks. It was fun to learn something new and rewarding to create something useful for the group. The file had about 8 pages of data. Some groups had 2 tables, some just one. It generated about 50,000 tuples, was easy to update and worked well for years.
In the late 1990's, after Adobe bought us, we got a new IT department. They wanted everything to be in the database, so they tossed out the system. Within a year, Adobe also downsized our teams, moving most of us off of FrameMaker. Shortly after, they moved FrameMaker maintenance to a small group in India... I was still working on FrameMaker. For a short while, I was helping with the next version of "structured FrameMaker." They wanted me to be the manager. Instead, I left Adobe...