Business Patterns for Software Developers

On Wednesday night I was in Edinburgh to speak to the local BCS group - I’m sure you remember the British Computer Society, that no longer exists, this was the Charted Institute for IT which just happens to be known as The BCS (obvious really). Anyway, I digress….

I was there to talk about the software business, or more specifically, patterns of software business…. OK, I admit it, I was there to plug my book Business Patterns for Software Developers - sales are going well, although I can always do with more and a few more reviews on Amazon would be well received.

The presentation itself can be downloaded from my website - Business Patterns for Software Developers - or viewed on Slideshare. There must have been 30 or so people there and the presentation was well received.

After the presentation there were several interesting questions which, time allowing, I’d like to reprise in this blog in the coming weeks. Right now I’ll stick to one question and answer.

One of these questions concerned the book’s title: Business Patterns for Software Developers. Someone said they had expected something more technical and they were a little confused by the title. Well, let me explain….

The choice of title was a little complicated. Partly because over the years the name “Business Patterns” has been used by some to refer to code level patterns. Lets be clear - BSP, as I call it for short, doesn’t contain any code.

(I call it BSP because the earliest drafts were entitled Business Strategy Patterns - have a look at the early patterns on my website. Over time I focused the patterns more and more on the domain I know best, software development.)

The title reflects two things - both of which are in the second half “Software Developers.” Firstly I am using the term “Software Developers” in the broadest sense, I am including anyone, or any organisation that creates software. Indeed, one of the earlier versions had the title as “Business Patterns for Software Creators” but that was felt to be a little vague.

Second, when I was writing the book I tried to imagine the reader. Who was going to read this book? What did they look like? Where did they come from?

The people I imagined were code-face hands on developers. People like the members of the ACCU. People who spent most days building someone else’s system and dreamed of building their own product someday. Some of these folk wake up one day and realise that they now hold a management position and they need to understand the business they are in.

In other words I segmented my market. I had personas for my readers. And yes, I imagined specific individuals reading this book. I won’t name them, I don’t want it to go to their heads, I’ll let them guess.

Actually, one person I will name: my younger self. In many ways the developer I was imaging was the younger me, the me that used to - sometimes still does - dream of creating a best selling software application.