I think it is fair to say that I have had an eclectic career in computing. I’ve worked for some of the largest computer companies in the world and I have spent a good bit of time in the classroom teaching. For about a fourteen of those years I had what I would call pure software development roles. Though I have written code for every job I have had for some jobs that was the main purpose of my work.
I spent some of my early career writing custom business software. Interesting, often fun, but it was a tough environment back in the 1970s. For about ten years I wrote and documented software used for testing large (think $10 million per system) computer systems. For about two years though I was part of an operating system development group.
Operating systems and the development of those systems was different in the 1980s than it is today. While I suspect that the Windows team has something like 1,000 people the RSTS/E development time was about 100 people. Windows has people whose job is to test software that other people write. Other people write original code while a different group fixes their bugs. I suspect that another group works on fixing bugs that customers report in released software. Maybe. Not sure. Back then members of an OS development group did it all.
While my main role was to write the user interface for a brand new, developed from scratch print and batch system I had other responsibilities. I had to look into bugs reported by customers for a number of different utilities. For example, if someone reported a bug in the backup utility or the login/logout utility I had to look into it and hopefully fix it. I was also responsible for making modifications to several utilities to support the major changes we were making to the OS. Oh, and I was the release engineer.
The release engineer was responsible for building the complete OS and packaging it for installation. I suspect that is a dedicated person (in not group) in most OS development groups today. As I said though, things were simpler back then.
Getting to my main role though. One of the things we were doing with this new version of the OS was to add layers of privileges. Previously, a user either had very limited privileges or unlimited privileges. That was increasingly seen as insecure and other operating systems had all sorts of privileges that could be set for different users. Pretty standard today but this was new for this OS.
This sort of thing has to be deep in the system. It complicates everything. So we were building a new system for printing files and running batch jobs (jobs that ran in the background without user interaction once started). My bit was the command line interface. The commands for starting, stopping, monitoring and generally anything the user was allowed to do. Oh, and writing the help file as well.
The manager of the team was a great guy. One of the best managers I have ever had. One thing he insisted upon was that we completely design the system before we started coding. And design we did. We had all sorts of flow diagrams, data structure layouts, and lots of though being given to the security of the system. We spent longer on design than any other sub group. The overall manager started to get worried that we would not make our timeline.
Long story short, we did make out timeline. Not only that but for years after the product was released I tracked bugs reported on the OS and none were reported for our part of the system. I am convinced that the time we spent on design is why we both finished on time and without reported bugs.
The design helped me to build my test suite as well. As I said earlier, we did not have other people testing our code. Each developer was responsible for testing their own work. I know that there is a theory that people should not be responsible for testing their own code. Theory being that they will avoid, subconsciously if not consciously, testing things that are broken. I don’t buy it. I think that people who have pride in their work will want it to work and will test it thoroughly. I think that the developer also has a better idea of what code paths there are and that need testing. Unpopular opinion perhaps but I believe that trusting code testing to someone else leads to sloppy work. Especially if someone else is going to fix your mistakes.
This was my favorite development job for several reasons. One is that it was a great team with smart people who were always willing to help each other. Another was a good boss. A boss can make a job feel great or feel like punishment. They set the tone It was also very cool to be part of a major software project.
I had access to all the source code for the OS and that was an amazing learning experience. Yes, I know that source code is available for open source OS today but that wasn’t the case back then. Being a part of the design for a major new release, working with the key people, was a unique experience.. It was also a great job because I knew that hundreds of thousands, perhaps millions, of people were using software I wrote to get things done. It’s a great feeling.
I wrote a lot of code over the years and I am proud of much of it. But that time at RSTS/E is one of my fondest memories.
across this button. It was given out by the hundreds at a conference in the 1970s. . What is the spirit of 100110 you ask? That represents the number 38 which doesn’t seem to mean much. And it really doesn’t because that is not the number that was supposed to be there.