Great Characters but the Script was Lousy

Nobody is likely to accuse me of creating great literary works, but I have written (and read) enough to know that you can tell a really good story without spending much time on character development. Really good characters can enhance a story, and great characters will inspire many additional stories (Sherlock Holmes comes to mind), but in general the characters exist to help the author tell the story.

I love analogies and metaphors... and in case you haven't already guessed where this blog entry is going; I'm about to make an analogy between writing stories and writing software.

My programming career began in 1980... and at that time (I kid you not) a friend was working on a Master's thesis (at UT Arlington ) to convince the non-believers that "Structured Programming" was more effective than using "GOTO" statements. We've come a long way...

By far, the single biggest influence on our collective programming psyche since 1980 has been Object Oriented Design: Encapsulation, Inheritance, Polymorphism. We (programmers) eat, drink, and dream objects. Objects are in our pores... We sweat objects.

Our Object Orientation tends to dictate how we approach new projects (aka: The Blank Page): When a client describes to us what they want their new whiz-bang software application to do, we almost always immediately begin decomposing their narrative into the objects that will perform the necessary tasks:

"We want some software to let our Customers fill out Loan Applications and submit them to the Bank. If the Customer has a good Credit History, then route the Loan Application to any Loan Officer for approval. If the Customer's Credit History is bad, then route the Loan Application to a Senior Lender instead."

Let's see... We obviously have a "Bank" object with a method "Process Loan Application". The "Bank" has a list of "Loan Officers", and "Senior Lender" is derived from "Loan Officer". The method "Process Loan Application" obviously has an input parameter that is a "Loan Application" object. The "Loan Application" object has a "Customer" object embedded in it... and the "Customer" object has a "Credit History" (We can certainly argue whether a "Loan Application" has a "Customer", or if it's the other way around, but please humor me for the moment).

Bank contains list of Loan Officers. Senior Lender inherits from Loan Officer.

Loan Application contains Customer. Customer contains Credit History.

Great... Now let's get to work implementing those Objects!

Going back to my writing analogy... I've taken the story that our client was telling us and extracted the Cast. I've identified the necessary Characters, and now I am setting off to flesh them out.

Objects are Characters

What I sometimes lose with this "sort of" OO decomposition approach is the narrative. I've lost the movements, the motions, the flow. I ended up with interesting Characters, but they'll just lie there on the page until the end of the book. Chapter One: The Structure of the Bank. Chapter Two: The Elements of the Loan Application... Impatient readers will have to skip ahead to the final chapter to learn what happens during Loan Application's Journey Through The Bank.

Back in my OO purist days (I would use the word "bigot", but that might offend somebody) I thought that everything should be an Object. I sneared at Linux because it was written in 'C' and I scoffed at Relational Databases. Everything would be so much cleaner if only everything was an Object. I've mellowed with age... and I've seen the error of my ways.

Scripts Describe What Happens

Perhaps my sensitivity to this issue stems from my early background in designing Graphical User Interfaces (ever heard of Tandy's Deskmate ? I thought not)... When writing a "GUI" application, you are almost always describing what happens: What happens when this icon is clicked? Almost everything is an Event Handler. When an event occurs (like a mouse click) it kicks off a short process (often written in a Scripting language like JavaScript)... and then you go back to listening for the next event.

Process Definitions are Scripts

(Process Diagram from Lombardi's Teamworks)

Neither of these models is "wrong"... and neither is "complete". We really do need both. A Script with no Characters makes little sense. Characters milling around without a Script usually ends in confusion.

Both models, Object and Process, are important... But which should come first? Is this just a "Chicken or Egg" question, or does the order really matter?

I submit that the order really does matter, and the Process Model should come first. "What Happens" really is the story... and if you don't get "What Happens" right you've wasted your time.

But wait... Isn't the Process just another Object? Well.... no. You can certainly use an Object definition to implement a Process, but it's a very constrained Object. For staters: There's only one public method (per Process)... sort of like Java's main. Is there any real value gained by insisting that a Process is an Object? I don't think so.

We all know that successful characters (like Sherlock Holmes and Indiana Jones) do spawn sequels... But it always takes a good story to make those characters a success in the first place.