Verbs, Nouns, Sentences and Conversations

So you've just won yourself a new client.

Or you've had an amazing idea for a new product (and validated it by building tiny prototypes and charging for them - ideas are worthless by themselves - you have to be sure people actually want to buy it).

You're excitedly running through how this fantastic new project is going to work. And suddenly it all feels a bit overwhelming.

Now if it's a product, then I actually don't start by thinking about the implementation at all. I generally start with a press release (and I'll publish my current side project's press release in a week or two). The reason is that the press release will have to capture the essence of the product - the stuff that your target customers are going to get excited about. So in six months' time, when you're deep in code, you can look back at it and remember what the product is supposed to be about and stop yourself going down dead ends.

But when I do get round to designing the product, there's a simple method that I use.

First a bit of history.

I write in Ruby on Rails.

Ruby is an object oriented programming language and Rails is an object oriented framework.

The very first object oriented language was called Simula - because it was intended for simulating items in the real world. Or rather - simulating objects in the real world.

The second object oriented language was called Smalltalk - because it was about objects passing messages to each other - in effect, having conversations.

These two concepts are central to object orientation but are very often forgotten.

But I use them when designing my apps.

First of all I run through all the things that will be in the system.

For my day-job, that's things like "Documents", "Folders", "Projects", "Revisions" and "Comments".

For my side-project, that's "Cards", "Boards", "Actions", "Questions", "Answers" and "Consequences".

These are my nouns and will become my objects. In Ruby on Rails terms these are called models.

Next, I think about what the user will want to do to those objects.

For my day-job, they might "upload a new revision", "move a document to a different folder", "add a comment" or "copy a folder".

For my side-project, they may "add a card to a board", "ask a question" or "record an answer", "perform an action" and "apply the consequences".

These are my verbs and will become the messages that my objects send or receive. In Ruby terms these are methods - but in my Rails apps, I've started representing them as a special type of object (which is helpful for controlling permissions and logging what’s been happening).

Now a very quick grammar lesson.

Note that some of the messages are intransitive - "ask a question" - and some are transitive - "move a document to a folder". The intransitive ones are just a verb and a noun. The transitive ones are a verb, a subject and one or more objects. However as object is a loaded term in OO languages, I call them targets. This point of grammar is important when it comes to designing the application - as we'll see in a minute.

There's one final piece of the puzzle.

Remember that the Smalltalk language was about conversations between objects.

The order that messages are sent and received is vitally important. This is partly why it's so hard to read other people's code - it's not just the code in front of you that matters but the sequences in which it's invoked. It's also why Javascript used to suffer from "callback hell" - callbacks, by definition, are out of sequence - and why async/await is so amazing.

Because this sequencing, these conversations, are so important, I try taking a few of the most important features - say "uploading a file" or "performing an action" and map out those conversations. Who says what to whom and when?

And once we've done that for a few of our features, suddenly, we've got a map of the vast majority of our system. All these nouns, what they need to say and who they need to say it to. Which implies, some nouns are going to have very close relationships with each other, other nouns will never ever meet.

What needs to go into the database? The nouns become our tables.

What are the joins and foreign keys? Those "close relationships" we just mapped out.

What do the main screens or pages look like? The nouns that are in frequent conversation with each other will end up being shown visually near each other.

How do we represent the intransitive verbs? Clicking on a link or a button would make sense in most cases. Maybe swiping or using a menu.

How do we represent the transitive verbs? Dragging one thing to another makes sense for simple cases, opening a form is good if further information is needed to complete the sentence.

And modelling this way - nouns, verbs, sentences and conversations - automatically fits with how our end user thinks about the system. We're literally using their language to describe it, which means they will understand how it works, will find it easy to use and will need much less support.

We've designed our system without writing a single line of SQL, Ruby, Javascript or ever drawing a UML diagram (shudder). Not bad eh?