Behavioral Software Engineering

Welcome to my new blog! By way of introduction, I am Ken Stephens, Ph.D. and I’m a Behavioral Software Engineer. The purpose of the blog is to discuss issues relating to software that supports a behavior-based safety (BBS) process. However, in this first installment, I want to give some background about software engineering from a behavioral point of view.

I have used the term Behavioral Software Engineering (BSE) for many years now – it’s been on my business card, and I’ve spoken about it at professional conferences. What do I mean by it? Quite simply, it’s what happens when a behavior analyst gets involved in developing software as a way of applying behavior analysis. It’s that simple, and it’s also that complex. I’ve seen many different ways in which software is put in service of behavioral objectives: examples that come to mind include computer software that controls our experiments in the behavioral laboratory; computer “courseware” that is used to deliver instruction and training; software that supports decision-making in uncertain environments; the design of user-friendly computer/human interfaces (also called software human factors engineering). The examples span the whole spectrum of problems to which behavior analysis offers a solution. For me, a BSE is a person who has been trained in behavior analysis (which is the scientific discipline of finding and manipulating functional relationships between the environment and behavior in order to change behavior) and who then plays a part in building the software to support that behavior change.

Let me give some examples from my own background. I first wrote FORTRAN programs to help me keep track of behavioral research I did as an undergraduate in 1973. The experiment itself was controlled by relays and digital logic and involved brain stimulation as a reinforcer for rats' pressing a lever. I wrote down the numbers from my counters, and entered them into my program so they would result in some numbers that fit in with other research on the Matching Law. I didn’t know anyone else at the time that was doing that, but of course they were, in operant labs all over the country. I had no notion that computers could actually control the experiment itself, only that they could crunch the numbers afterward. My programs were in the form of decks of punched cards, which were read into a Sigma Seven mainframe computer. You’d wait hours to find out that you had a syntax error in one of the statements.

On the basis of that primitive experience, when I went off to grad school at Western Michigan University, I was assigned to Dr. Arthur Snapper as his assistant. Art was developing the SKED process control language, which ran on a PDP-8 computer in as little as 8k of memory (!!) to control the relay circuitry that interfaced with the experimental chambers (which were basically “Skinner boxes” for rats and pigeons). Art was the first BSE I knew, and I am still in awe of the work that he was doing, even though I understood very little of the inner workings of his programs (a compiler and a run-time system) which he wrote in the PAL machine language. During the years when I was Art's assistant, I helped document SKED and teach it to other grad students, and I wrote SKED programs and the FORTRAN to analyze the results. The experience I gained working with Art really helped propel me along the path that led to where I am today.

One interest that came out of those years was in “computer assisted instruction,” or CAI. Soon after I left the research world, I put together a small team of instructional designers and programmers for a government contractor to do “embedded training” and other forms of training/instruction delivered by computer. At the same time, I had to master some of the underlying technology, as I served as a system administrator and systems programmer for a VAX-11/780 system.

During this time, I met Dr. Bill Hutchison, who was developing a kind of adaptive system based on theory from the psychological laboratory. His software system evolved during the years that we had a company called BehavHeuristics. It was the basis of a decision support product that we sold to the airline industry. Our biggest client told us that by their conservative accounting, it generated $140 million additional revenue in the first year of operation, just by selling the seats smarter. Bill’s system combines his approach to “neural networks” with genetic algorithms. It was up to the task of showing basic verbal capabilities as early as 1994. We subsequently started another company, Applied Behavior Systems, to market software that was remarkably effective at teaching autistic and developmentally-delayed individuals simple language. Later, Bill applied it to the problem of controlling robots. Bill is a BSE, for sure.

At BehavHeuristics, we hired Dr. Bruce Lombardi to be the Vice President of Engineering. Bruce’s PhD was in behavior analysis, but he also held a masters degree in software engineering. Bruce is an expert in object-oriented design and development. He’s a BSE.

At Applied Behavior Systems, we probably had the world’s largest collection of BSE’s at that time. One of them was Dr. Bill Potter, who is a professor at California State University at Stanislaus. Not only was he an expert in verbal behavior, who could contribute from that perspective, he wrote some of the Java software that we ended up using in our SpeechTeach product. Bill Potter is a BSE.

I’ve had the privilege of knowing dozens of others who I consider BSEs: Donald Cook, Duane Dregits, Eleanor Criswell, Mac Parsons, George Lawton, Betsy Constantine, T.V. Joe Layng, Will Vaughan, Tom Donaldson, Tim Elsmore, Geoff Inglis, Bob Dingler, Matt Morris, Roger Ray and many others. By understanding and modeling the underlying behavioral processes in whatever application we work on, we bring a different kind of sensitivity to the software that we develop. That’s what I mean by Behavioral Software Engineering.

For the past several years, I have developed a web application for supporting a behavioral safety process. In future installments of this blog, I will focus on that, and some of the issues in collecting and storing behavioral data.