A Unifying Metaphor in a Talk Abstract

[Joshua Kerievsky]

Hi Folks,

I thought I'd share an experience I had a few months ago while writing a talk abstract on the topic of Sufficient Design.

Here's the first version of the talk abstract that I had already edited extensively before sharing it with colleagues to get feedback:

--------

Not all of a product's features are of equal importance to the product's users.

Some features form the heart and soul of a product, some features play a supporting role and some features are like plumbing.  

What criteria do we use to decide how much quality to put into the design of a software feature?

How do we successfully blend Lean processes with Software Craftsmanship?

If we are going to be "agile" don't we need to decide how and where to invest our time and energy?

In this talk, we will answer these questions by exploring the philosophy and practice of Sufficient Design.

--------

With some feedback, I made some minor improvements to produce this version of the talk abstract:

---------

Not all of a product's features are of equal importance to the product's users.

Some features form the heart and soul of a product, some features play a supporting role and some features are like plumbing.  

What criteria do we use to decide how much quality to put into the design of a software feature?

How do we decide how and where to invest our time and energy?

Sufficient Design answers these questions and points the way towards how to blend Lean processes with Software Craftsmanship.

---------

Yet something was still not right.  So I asked for more feedback and ended up in a Skype chat with my colleague, Bill Wake.  

Bill didn't like that I had essentially 3 metaphors in the abstract: "heart and soul", "supporting role" and "plumbing."

What a great point!  

So I rethought the entire abstract because I wanted it to be really good.

The metaphor I liked best involved the "supporting role" or "actor" idea.   

So I riffed on that and ended up writing what I now deem to be a far better talk abstract that is unified by the movie metaphor:

---------

If your software product were a film, which of its features would be a movie star, a supporting actor or an extra?  

Should you invest more in the software design of star features, especially if they generate the most revenue?  

And if so, what level of design quality is sufficient for features that are supporting actors or extras? 

Doesn't Software Craftsmanship tell us that we need to write clean and simple code, regardless of its role?  

Or, if we are Lean and focus on increasing the speed of concept to cash, will quality suffer?  

Sufficient Design answers these questions and points the way towards how to blend Lean processes with Software Craftsmanship.

---------

This experience reminds me of the kind of substantial improvement that can be made to a software product or software design when a good product or system metaphor is discovered and used. 

--
best,
jk

--
Joshua Kerievsky
Founder, CEO
Industrial Logic, Inc.
Web: http://industriallogic.com
Twitter: @JoshuaKerievsky, @IndustrialLogic

Amplify Your Agility
Coaching | Training | Assessment | eLearning

[Steve Freeman]

An interesting metaphor for prioritisation. To stretch it beyond breaking point:

- some movies are small ensemble pieces, some have lots of anonymous villains to be gunned down. Choose appropriately.
- no extra can make a movie, but any one of them can mess up a shot.
- the stars attract the big money, but established character actors can make a good living and don't fall out of fashion
- nowadays, large crowds are generated automatically. No need to have real extras at all.

S.