It’s been a (long) while, but I’m finally back to continue my discussion of Dan Teasdale’s Design Lessons Learned From Rock Band. Dan brings up issues of design, re-design, software development cycles, management, communities and dealing with the unexpected that are much more universal than just game design. I discussed the One Question Principle in the previous post, and in this one, I’ll consider the second principle he discusses – the Perceptual Control Theory (PCT).

The What What What?

If you’re wondering what, it doesn’t really matter. You can read the Wikipedia page , but Dan only refers to a single element of the whole theory, and here’s the relevant Wikipedia quote:

When two systems are controlling the same variable with different goals, they are in conflict. When two opposing systems are locked into a static pattern, it is a source of psychological distress.

And also:

An internal conflict exists when a patient wants a perception to be in two incompatible states; the patient wants but doesn’t want a certain perception. For example, a person wants to eat in a healthy way but winds up eating too much or eats the wrong things.

Bear in mind that this theory relates to living organisms (animals, humans) but also to automatic systems. To sum up, we are talking about the case where someone, usually your customer, wants two different things to happen in the same time – he wants automation, reliability and simplicity, and at the same time, he wants control, versatility and transparency. Since your product can compromise these two ends, at best, the real problem is not in your product, but in how it is perceived by the customers. This perception is something you can control.

Take, for example, our BEEHD application.

SDK vs. Application

RADVISION’s Technology Business Unit (TBU), which I am part of, “manufactures” mostly Software Development Kits (SDKs), or “Protocol Stacks” as we fondly call them. These stacks translate the application’s “wishes” to the protocol level, meaning that if the application wants to send some indication, it calls the appropriate Stack API, and the stack builds and sends the appropriate message, notifies the application as to the response, etc.

However, applications written above the SDK tend to have “special needs”, for instance they want specific changes in the messages or proprietary messages. That is why our SDKs have a lot of hooks and callbacks, allowing application level control over even the most basic functions of the stack.

The BEEHD, for instance, is a rather closed application. Well, it’s almost closed – the APIs are the closest we could come to GUI buttons (while leaving the actual graphics to the customer). Some customers are ok with that, and are actually glad to leave concerns such as interoperability to us. Other customers are, well, used to working above SDKs, and their major complaint are “why can’t we change this?” or “why can’t we do things another way?”

There are a few possible answers:

1. Explain that this is an application, not a SDK, and it doesn’t work that way.

2. Change the application to allow the SDK-level access.

Both are pretty problematic: with option 1, you get frustrated customers; with option 2, you enter debugging hell when your application logic tries to cope with all the strange changes that the SDK level access imposes on it.

Higher Level Control Systems

As we learn from the PCT, “An internal conflict exists when a patient wants a perception to be in two incompatible states”. However, we also learn that “Higher level control systems may seek perceptions that don’t produce the conflict”, meaning that if our customers have a conflict resulting from conflicting needs, we but invoke higher level systems to resolve the conflicts – so we did.

What we did is sit down with the customer to talk, and reach answer no. 3:

3. Add the required (low-level) features as services controlled by (high-level) APIs.

Notice the difference between a feature, such as “add this field to that message”, and a service, such as “be compatible with this device” – services are our higher-level control systems. Simply put – we learn from our customers, and improve our product for the next customer. Think of us as car manufacturers adding a sports mode to accommodate the ‘sporty’ drivers and not just the ‘calm’ ones. The car is a “closed application”, but instead of forcing hot rods to mess with the engine to squeeze out more performance, the car is made with a high-level control to accommodate them.

To prevent the distress from occurring in the first place, we could add to the product description something like “the BEEHD application supports several services and modes of operation to accommodate different environments and requirements. If you cannot find a suitable service in the current offering, please contact RADVISION’s customer support with the required services, and we will implement one according to you needs”.