Essence and Problem Solving Blog

August 12, 2014

Three Great Book Titles and One That Missed the Mark: Part II

In last week’s blog I explained how I whittled down a long list of possible titles for my latest book to the following top four choices:

  • The Essence of Improvement
  • 15 Fundamentals for Higher Performance in Software Development  
  • Better Decisions Through Better Practice With Patterns
  • A Framework Vision for Higher Performance in Software Development 

Only one of the titles came close to meeting Peter Gordon’s rule of keeping the title to three words or less, and that was “The Essence of Improvement”.  I liked this title for one main reason besides its length.  I worked with Ivar Jacobson and our co-authors on the “The Essence of Software Engineering” book which focuses on the essentials—or common ground—that always exist across all software engineering efforts. 

I was originally thinking when I started to write my latest book that I was going to distill “the essentials that are common across all improvement efforts”, and so the title “The Essence of Improvement” seemed perfect.  But as the book evolved based on reviewer comments, discussions, and my personal analysis of past experiences working with multiple clients, it became clear that what I was talking about in this book was not common at all.  In fact, the 15 fundamentals– while they seem simple on the surface— are rarely achieved or thought about in most organizations today. 

There was also another problem with this title.   While I have found value in these fundamentals in my own personal improvement efforts as discussed in the book (e.g. golf), the vast majority of the examples I provide relate to software development.  So the simple “Essence of Improvement” title was reaching too far without sufficient research and proof into what it takes to improve and sustain improvements in other endeavors. 

If you read my two blogs over the past few weeks about Practice Slices and Patterns you should have a good idea why “Better Decisions Through Better Practice With Patterns” would have been a great title for this book.  The value of patterns is a key point that I highlight in this book, and I provide many pattern examples from my software development experiences both as a practitioner and as a coach. 

As I researched the pattern idea I became increasingly excited when I found numerous examples of similar experiences to my own in areas that had nothing to do with software development.  Examples include the idea of “thin slicing” discussed by Malcolm Gladwell in his book “Blink: The Power of Thinking Without Thinking”.  

A second example was found In Daniel Kahneman’s book, “Thinking Fast and Slow”.  In this book Kahneman explains how we can improve our quick–or intuitive– thinking by learning to recognize common situations rapidly.  This idea fits perfectly with my own experiences in software development, especially when rapid decisions need to be made by software practitioners on a high pressure project when a deadline is approaching. 

My favorite story that I convey in my book to explain the power of pattern recognition among athletes I borrowed from Jonah Lehrer’s book, “How We Decide.”   This is the story about Tom Brady, Quarterback for the New England Patriots football team in the National Football League.  In this story the reader learns how Tom prepares for football games which gives you an idea why he is such a great quarterback when the original scouting reports indicated he would never make it as a professional athlete. 

The analogies between what Tom does, and what I have found software practitioners can do to help prepare for typical situations they face each day– especially on a high pressure software development project—may well be the most compelling part of my book.  This also turned out for me to be the most rewarding part of my research and work in writing this book.  For that reason this title was my own personal favorite.  It was also Bill Fox’s favorite. 

A late entrant into the list of possible titles was “A Framework Vision for Higher Performance in Software Development”.   I liked this title because the framework vision, which I added just in the last few months of writing the book, turned out to be a major strength of the book based on comments from a number of my reviewers. It was exactly what was needed to help people understand why we need a framework like the Essence Framework.  Creating this framework vision also helped me personally– as one of the volunteers who developed the Essence Framework—to step back and see more clearly the bigger picture and the need for a framework such as Essence.    

The Essence framework is difficult for many people to understand when first exposed to it for a number of reasons.  One reason is because it is not immediately evident to many people why we need this new framework, or what problem it is solving that other software frameworks have not been able to solve.

By presenting the framework vision in the book using very simple non-technical language it helps the reader to first understand what is needed and why we need it, before we talk about a specific solution. 

 If you take the time to read my book– whether you like the Essence framework or not– I would love to hear your feedback on whether you agree or disagree that the software community needs a framework that fits the needs of the framework vision as I describe it in my book. 

But when the voting was done, the majority of my reviewers polled preferred the title that highlighted the 15 Fundamentals.  What is it that resonates with the idea of the 15 fundamentals that I highlight in this book?

First, these fundamentals are not what many might expect to see in a book about fundamentals and software development.  You will not see Requirements, Design, Programming, and Testing mentioned.  This is because this is not a book about the fundamentals of developing software. It is a book about the fundamentals of performing at a high level and sustaining that performance even under difficult and often adverse conditions–which are not at all uncommon in today’s fast paced and competitive world– when developing software.

Second, in this book I am calling for a culture change in how we implement process improvement today in organizations. A key point I raise is the fact that the speed of change we are all witnessing in today’s world requires that we step back and take a serious look at the process we are using to help our people get better at what they do. 

It is my contention that we need a far better way than what most organizations are doing today to empower our teams to take ownership for improving their own practices and their own personal performance. 

The 15 fundamentals I present in this book are my way of helping you think a little outside the box about how you might help your own organization get started down this path.  If you only take one or two ideas from my 15 fundamentals that can help you make even a few small changes in your organization that can start you down this road, then my ultimate goal in writing this book will have been achieved. 

Love it or hate it, I would love to hear what you think. 


  1. I think the title we need should be Engineering Software Quality (3 words)
    but then I did that,
    and Semat does not ‘get’ the engineering paradigm. Programming will NEVER get the multiple qualities engineered in.

    Comment by Tom Gilb — August 14, 2014 @ 2:10 pm | Reply

    • Hi Tom,
      Thanks for the feedback, but I am not sure why you say, “SEMAT does not ‘get’ the engineering paradigm.” The Essence framework intentionally includes no practices so that each organization can provide what is appropriate based on factors specific to their organization, domain, and stakeholder needs. I haven’t read all of your “Competitive Engineering” book, but I have read a lot of it and I see nothing in your ideas that would conflict with anything in Essence. In fact, your approach to engineering software quality could be described as a set of practices on top of the Essence kernel.

      Comment by pemcmahon — August 14, 2014 @ 6:44 pm | Reply

      • Hi again Tom,
        Let me add to my last comment. Someone might immediately be thinking, why would Tom Gilb want to express his approach to engineering software quality on top of the Essence kernel? One possible reason might be that it could be a way to express the strengths of certain areas of your practices over certain other approaches. Once these strengths were visible on top of the neutral Essence kernel, then people who had greater interest might be motivated to go read more of your book. I think you even admit in the front of your book its not an easy read, so this might motivate people once they saw the strengths of your approach demonstrated on a neutral framework. This is part of our SEMAT vision. To help people compare practices and methods and make better decisions in the future given their specific context.

        Comment by pemcmahon — August 14, 2014 @ 6:59 pm

  2. Ok thanks Paul. Maybe someone can help me see exactly, diagram or table, how my ideas fit in a SEMAT framework.
    That might be a useful pattern for other similar efforts.

    I don’t feel the need for frameworks. Perhaps since what I have is a sort of framework. But it also has muscle on the bones.

    But then I’m not an academic or an organization who might feel the need for frameworks.

    I do like to get down to generally applicable fundamentals. Which is why I have so many stated principles.

    R W Emerson said

    As two methods there may be 1 million and then some, but principles are few.
    The man who grasps principles can successfully select his own methods

    I still do not understand what SEMAT says about engineering in the framework. But maybe we need a shared definition. I have a Planguage definition due to Koen.

    Comment by Tom gilb — August 15, 2014 @ 11:02 am | Reply

  3. Hmm it seems like your website ate my first comment (it was
    super long) so I guess I’ll just sum it up what I submitted and say, I’m thoroughly enjoying your
    blog. I too am an aspiring blog writer but I’m still new to the whole thing.
    Do you have any tips for rookie blog writers? I’d definitely appreciate it.

    Comment by personal — March 30, 2020 @ 3:54 am | Reply

    • Thanks for the comment. The best advice I can give an aspiring blogger is to know the main point you want to make and leave the reader with. Then just write naturally as you would talking to someone standing next to you. Lastly, after you finish the first draft spend a lot of time shortening the way you say what you want to say. This last part is usually the most time consuming, but your readers will appreciate it.

      Comment by pemcmahon — March 30, 2020 @ 1:18 pm | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at

%d bloggers like this: