In a previous post, I linked to Dan Teasdale’s design lessons, as learned from “Rock Band“. In this post, and in the next few posts, I will analyze Dan’s ideas for game development, and try to apply them to development in general.

The first principle Dan mentions is “The One Question“.

Decisions, Decisions

Software development is a series of decisions. The Product Manager, customer and/or Project Manager (or equivalent) can provide requirements, statements of work, high-level design, even low-level design, but the person doing the actual coding is still left with many decisions:

• How to initialize?
• How to destruct?
• Which events should be synchronous?
• Use more or less parameters?
• What should be the exact call flow?
• What to do in an error case? Handle automatically or consult the user?

All these decisions could annoy your customer, but they could also make him love you forever. Do you know the feeling you get when something works just as you expect it to? It’s a Zen kind of feeling, of being one with the universe. You want that for your customer.

Dan Teasdale’s method for achieving this is called “The One Question”, meaning that instead of micro-managing every decision your team makes, you present them with a question that defines the essence of the product. Then each decision a developer makes is inspected in light of the One Question, as the result has to fit the question best.

The example Dan makes is related to the development of “Rock Band”:

“Is it an authentic band experience?”

• Big Rock Endings – yes
• Powerups – No
• Back from the Brink – yes
• Guitars on Fire – No
• Solo Bonuses – yes
• Minigames – Big No.

And Now for Development In General

Can one question, the “One Question”, really define something other than a game? Can it define an SDK – something that means different things for different developers?

The best way to test this is by trying to ask the One Question regarding our new and shiny BEEHD product:

Is this a high-end (video) phone experience?

I put ‘video’ in parenthesis because people may not have much experience with video phones, but we definitely know what to expect from our phones. And we know high-end experience from a low-end one. Different people may have different ideas as to how a “high-end video phone experience” should be, but this is true also for ideas of what a “rock band experience”.

Let’s try to make some decisions in view of the One Question we just asked:

• Simple, easy to understand state machine – Yes
• Low-level configuration – No
• Automatic error recovery – Yes
• Interactive operation – No
• Smooth video – Yes
• Delay – Big No

Surprisingly, this seems to work very well.

Now, what about SDKs? Let’s try to ask a question defining the essence of our Diameter stack:

Can it be used to build a robot army and take over the world?

Extreme question, I admit, but my first thought was of Star Wars, where Obi-Wan goes: “these are not the droids you are looking for”…

Pffft, Clones. This would not fly with my robot army. Every robot on the planet should be able to authenticate and authorize (or deny) and droid certificate. And they should do it quickly and reliably. So let’s make some example design decisions:

• Multiple levels of APIs – Yes
• Automatic error handling – No
• Network error resilience – Yes
• Static resource usage – No
• Expandable in every possible way – Yes
• Jedi Mind Trick prone – Big No.

It works well for SDKs too. This could potentially replace the classic product manager interface for answering every little design question. And it also relates well to Agile programming, if you’re into that. This would also be a good guideline for QA – test this like it’s going to go into a robot army, test that as if it’s a high-end communicator.

The One Question paints a big red target for where you want to go. Some developers may still miss the mark, but it will get everyone aiming for the same direction.