Part of Ken Stephens response to my questions about folks doing behaviorally oriented software:

Were we the first CAVB people? Hard to know -- when I came out of Snapper's lab, there weren't many of us with software and VB skills. You were aware of who was thinking that way at WVU. Donald Cook would have been putting two and two together. Possibly George Lawton. I started getting serious about a behavioral alternative to all the cognitive crap out there in about 1980 when I read Ben Shneiderman's book and thought there has to be a better way. Bill Hutchison started his work around that time. The team we put together at ManTech had the potential to do great things, but it was the wrong place at the wrong time. I wish you had been able to stay with us longer, and that they could have seen our potential, but it wasn't to be, at least not there.

There was a Computer Modeling of Behavior Group in the early 90's composed of Bill Hutchison, Bill Potter, Donald Cook, Betsy Constantine, David Palmer and myself (what a group). We were centered around Bill's Seventh Generation agent software. I know a few other behavior analysts with software skills who fit this mold. Still not many, but more than we had before. Joe Plaud, who took over from me as webmaster at the Cambridge Center, is pretty sharp, and has some technical skills. Joe Layng is also technically savvy. Obviously, there are many that I'm overlooking simply because I don't know them, or because they "dabble" in software instead of combining software engineering with behavior. The term I'm using these days is "behavioral software engineers." I think our new company has the greatest concentration of them on the planet!

Excerpts from my email responses regarding skills needed for a position that was open for a short time with a previous employer. I was trying to find a way to get a behavioral person's foot in the door within my engineering team:

... we need someone with an integrated skill set. Plus, the person needs to be a good enough software engineer that we could use them in other tasks, as well. In many ways the software engineering skills are more important than the behavioral skills. We could hire a good software engineer with or without behavioral/cognitive psych skills; we could not do the reverse.

I suppose what I am looking for is a Behavior Analyst with a strong minor in computer science and who is using the computer science skills to design and implement behavior analytically informed software.

It is probably no accident that the cognitively oriented software folks generally come from specialized programs that train both sets of skills. Or rather, they attempt to. If I were rich, I would love to fund development of such a program (hope the stock market starts cooperating!). It would have a very heavy Behavior Analysis emphasis, but would also include serious computer science requirements. It would have a focus on the study and critique of areas such as artificial intelligence, artificial life, natural language processing, natural language "understanding", human-computer interfaces, and so on. Where would such folks publish?

[we recently spoke with] a traditional AI person ... His interests were in language understanding, that is, software that "knows" enough about what a person is saying to extract concepts, explain what topics the users is talking about, and perhaps translate into other human, database, computer languages. He never seemed to get the fact that what we care about is NOT understanding (as academic AI folks understand it, understand?), but rather we simply want our systems to provide the services desired by our users, based on user behavior in system contexts (e.g., sports pages versus financial areas), and past experience with the particular users.

For us, the things that are of interest to cognitive software folks are of incidental interest; they are design and implementation details, rather than the meat of the problem. For us, the important aspects of the problem are what the software does in response to user interactions with the system over time, NOT the internal structures used to support the interaction. I have worked with cognitively oriented folks who emphasized that the internal structure is what is important, not the relationship between the observable events. In some ways, the difference parallels the behavioral/cognitive difference in other areas. Cognitive folks do great research sometimes, but they consider the inferred internal cognitive structures to be the important aspect, whereas behavioral folks consider the relationships between observable events the most important. Where behavioral folks use the observed relationships to explain, predict, and control, the cognitive folks use the observed relationships to infer internal structures, then use the inferred internal structures to explain and predict behavior. This extra degree of freedom introduces GREAT opportunity for error!

One interesting conversation I had with a cognitive psychologist several years ago centered on the fact that if you teach a child to work math problems stated in the form "1 + 1 = ?", the child will be very unlikely to be able to solve problems posed in the form, "If you have one apple and someone gives you another apple, how many apples will you have?" (or was it the other way around? has been 15 years) For this particular cognitive psychologist, it seemed that the child should be able to generalize, because the internal cognitive structures to solve the problem were identical in both cases (I over simplify, but you get the idea). The question of how much the stimuli differ in each case was irrelevant to the cognitive person. No behavioral person would expect such generalization. So, not only do cognitive folks make weird mistakes because of their emphasis, they waste vast resources and time doing in the process.

KISS #1

Keep It Simple, Stupid. As few moving parts as possible, but no fewer.

KISS #2

Keep It Scalable, Stupid. In Internet-World, the rule is millions of simultaneous users, and growing. Some keywords: Reentrancy, distribution, modularity, multithreading, graceful degradation, portability, interoperability, caching, configurability.

Pi Rule

Make your best guestimate regarding the effort required to accomplish any task, using whatever metrics you wish, taking into account human resource issues such as downtime. Then multiply your estimate by pi to get the actual effort required. This "Pi Rule" has proven itself to be 90% accurate over a wide range of situations, by a great many software developers, over a long span of years.