Safety First

Quite early in my career as a computer programmer I came to the realization that the computer was a kind of universal machine. Given the right peripherals, it could print books, play music, build cars, and so many other things that one might imagine. In fact, imagining it was the first step in accomplishing it with a computer. With computers the key was to associate binary numbers with ever more sophisticated abstractions until you subsumed the problem domain in your digital model.

In recent years I have become aware of the fact that there are different categories of software. There is entertainment software that has little in the way of safety concerns associated with it. I don’t think anyone has ever been killed because of a bug in a game.

Then there is the other end of the spectrum, safety critical software. This includes such domains as automobile engine software that can cause an engine to explode if the parameters are set too far from nominal. Or flight software that can mean the difference between a safe landing and flaming death.

Between these two extremes are various levels of concerns when it comes to software accuracy. One of the examples in this middle area are financial programs that, while they can’t directly cause death, can reek havoc with peoples lives and reputations.

Software is comprised of a broad spectrum of applications each one with a more or less safety critical implication. One size does not fit all. Some software can be churned out as fast as the programmer can hit the keys with minimal programming and no one will be hurt. Other software needs lots of analysis, study, and design, followed by careful implementation and test. And even though all of this is done, we are still going to find bugs in the system. Software is a reflection of the programmers mind and all minds are flawed to some degree or another.

There are steps that can be taken. Breaking things down into small, clear steps, ensuring that multiple people examine code and understand it so that they can help catch errors before they can escape into production systems. And a commitment to professionalism by programmers on a par with our fellow creators from other engineering disciplines.

For the bulk of my career people have been amazed that computers can do the things they do at all. We are only now beginning to ask the more important questions about which tasks should be entrusted to computers and how much are we willing to spend to get software right. We have spent so many years on the quest for ever more impressive features we have forgotten the principle of staying with software that has proven to yield safe results. Forego some of the flashy features in order to ensure the soundness of the features that are already implemented. And remember, just because you can solve a problem with a computer, doesn’t always mean you should.

Planning is Everything

I’ve been thinking about planning and scheduling lately. No, not in the sense of writing software to automate some of the more tedious aspects of planning and scheduling. Although, the thinking I do about planning my time to allow me to make progress on all of my writing goals and creating a schedule to allow me to ensure I set aside time to work on them will undoubtedly help when I turn my attention to writing software of that sort.

I’ve done a reasonably good job of writing a minimum of seven hundred and fifty words a day in a journal for the past ten years. Usually, the goal here is to empty my mind of the various detritus that clutters it up and keeps me from focusing on creating stories and essays. On occasion though, most notably during National Novel Writing Month (NaNoWriMo as it’s often called), I use my journal habit to help find time for a more focused pursuit, like writing the aforementioned novel. The point is, I’ve developed a habit of writing my journal every day. Now, I need to figure out when I’m going to set aside time to write fiction on a daily basis.

But writing fiction isn’t the only activity vying for my limited time. There is also rewriting, editing, proof reading, and all the other incidental activities requisite in producing a polished, publishable product. And that is not even considering finding time to write and lightly edit the weekly blog post that I committed to this year. The one that you are reading right now in fact.

I have good intentions of writing several blog posts in advance so that I don’t get in a time crunch and find myself writing my blog post at the last minute in order to publish it every Monday at noon as planned. That hasn’t happened yet although I do have some hope of getting a few posts ahead before we get too much further into the year.

Dwight Eisenhower once said “Plans are worthless, but planning is everything.” It has taken me a while to appreciate the wisdom behind that statement. The way I’ve come to understand it is that the process of planning forces you to think about how to accomplish the activity you are undertaking. The plan that you come up with is merely one way of accomplishing the task. There are other ways of doing it, some better, some worse.

When you set out to execute a plan, you discover all the details that you overlooked while planning. The good news is, you have given some thought to the details that you didn’t overlook, thus reducing the amount of work you have to do while replanning in the moment. Also, you have practiced thinking about the problem so you have a better idea of where to start when you are considering how to proceed when you are replanning.

Habits help. If you can do something every day for two weeks, you will have established it as a habit. Once you have established a habit, adding a new aspect to that habit is a lot easier than establishing the habit was initially. For example, I have a strongly established habit of writing a journal entry every day. When I decided to add a practice of identifying three things that I was grateful for each day, I tagged that activity on to the end of writing my journal entry and established the habit immediately.

Take time to list your goals. Then prioritize them. Take the highest priority goal and schedule some time, fifteen minute a day perhaps, to dedicate toward achieving that goal. Keep that daily commitment for two weeks. Soon you will have achieved your highest priority goal. Take the next goal on your list and do the same with it. You’ll be surprised at how quickly you will start achieving your goals.

From Humble Beginnings

While reading my dad’s journal, I was reminded about a toy I got once for Christmas. It was called a Jimmy Jet. It was a mockup of a fighter jet cockpit. There was a display screen and a steering wheel. There was a throttle that made the engine noise rev up and wind down. There were two plastic missiles mounted on top that you shot by pulling a lever. I found several videos about it on You Tube. There was also an unrelated poem by Shel Silverstein called Jimmy Jet and His TV Set.

I had forgotten all about the Jimmy Jet. I even forgot what it was exactly until I Googled it. But as I watched the video of it in action it became clear to me that this was when I fell in love with gadgets. In subsequent years I tinkered with guitar amplifiers, radios, and old TV sets. I took electronics in high school. And when Popular Electronics had a cover feature on the Altair 8800 personal computer I was smitten with gear lust.

I got my first taste of computer programming on an educational time sharing system named Plato. There were two terminals in a room in the library at Southern Illinois University (SIU) Carbondale. They were connected by phone lines to a mainframe in Champaign. The system was programmed in a language called Tutor, a name inspired by the educational orientation of the system.

Tutor was influenced by a number of early computer languages. It was organized in units that corresponded with display pages. The display was made from glowing orange dots on a brown background. You could draw line graphics on the display or you could position text at any given place on the display. The text characters were user programmable so I created a special character set to animate a cat walking across the screen.

My next experience with computers was when I took the basic computer class at Redstone Arsenal in Huntsville, Alabama. It was 1976 and they were using a computer trainer built to work like a DEC PDP-8. Each computer had a teletype for a console with a paper tape punch/reader to store and load programs. I loved programming in machine language. We wrote the programs on paper, translated the instruction names into numerical codes by hand, and then punched them into paper tape to load into the computer.

By this time, I was totally hooked on computers. I subscribed to Byte magazine to learn about all the new personal computers that were coming on the market. There were articles about how to build add ons for your computer, how to program it, and even how to build it from scratch. I never had the money or skill to build a computer totally from scratch.

The next computer I was exposed to was the Burroughs 5000 minicomputer that served as the launch control computer of the Pershing Missile system. We learned how that system worked, circuit by circuit, board by board. By the time we were through, we knew how digital computers worked, inside and out.

When I got out of the Army, I got a job as a computer technician and programmer at a little startup in Alabaster, Alabama. They specialized in adapting personal computers for business use. Unfortunately, their knowledge of computers far exceeded their business acumen.