Book review: Crossing the Chasm

I wish I had read Crossing the Chasm (Geoffrey Moore, 1999) sooner. Not only does it give some good advice to technology (specifically software) companies but it also explains a lot about the technology and software market place. I guess I’ve known the basic argument Crossing the Chasm makes so I’ve never felt compelled to read it until recently. However I’ve missing out on so much more.

The basic premise is that for any technology product the buyers can be divided into five types. Initially the product sells to Innovators, then Early Adopters. While these groups will buy the product early they are quite small. Many companies sell to these segments and it looks like success but they are only addressing a fraction of the potential market.

The challenge facing a technology company is to break out of these two groups and sell to the much bigger Early Majority and then the Late Majority. These groups are so much bigger they represent the big money. (There is also a small Laggard group bringing up the rear but this is another small market so its not worth bothering with.)

The problem facing companies is that selling to the Early Majority segment requires a different approach and different strategy to selling to the Innovators and Early Adopters. In fact, while selling to these two groups can be profitable continued success here can harm your attempt to break into the Early Majority. This is where the Chasm comes from. Moore says that the difference between the first two and the third group is a Chasm, it is absolutely massive.

What Moore does is explain this problem and sets out a solution to overcoming it. The solution will be familiar to anyone who has followed my arguments on product management. The argument is also familiar from a bunch of other books too. The familiarity of this argument can probably be traced back to Moore anyhow. And the solution is...

To decide who you want to be your customers. To understand their problems. To craft a product that directly addresses your customer problems. To designate yourself the market leader in the field and make you solution utterly compelling.

It might seem an odd idea to declare yourself the market leader but what Moore says is: find a niche with your customers, define the niche so that you are the only people in it, then the niche is yours. It doesn’t matter if the niche is small to start off with - in many ways the smaller the better. The trick is to win one niche, one vertical market, then move onto the next. Over time you roll up the markets one by one.

I’ve worked with many software technology companies and I’ve seen many of them try to do this. Some successfully, most less so. Some of them knew they were following Moore's advice but I think most of them were following it by default; i.e. they find their product fills a niche but don’t set out to do that. In these cases the companies have trouble moving from one niche to the next.

The main problem I see with companies following Moore’s advice is the need to say No. To select and dominate a niche companies need to focus on this niche. Most companies find it impossible to say no to a potential sale. The company’s software can be used for many things, the idea of turning a potential sale down is just not possible. Consequently they end up being all things to all men. Sure they take the sale for good reason - its money - but the short term fix damages the long term strategy.

And there you go. There is the link. You need a strategy. You need your sales-force and your development efforts to follow the strategy. Not to sell outside the niche and to develop products with features which directly assess the niche. Once again this is the role of product management. You need someone to do this.

So, if you are in the tech business, and especially if you are trying to create a successful technology company read this book. It is well written and easy to read. It might not be the strategy you follow but you should at least understand it. If you don’t follow Moore’s strategy you should know why you are not and why your strategy is right for your company in your market.

Software requirements and strategy

I have been on holiday for the last week so it has taken me some while to get around to linking my last blog entries. Still here it is, better late than never.

A few weeks ago I wrote about the role of requirements in software development, and then I wrote about business strategy. What might not be obvious is that: in order to have product requirements you need to have a product strategy, and a product strategy needs to come from corporate strategy. If you lack either you might still go through the motions of developing software but it is unlikely that it will meet market or business needs, and it is unlikely you will have a successful product.

This happens in all industries but is particularly important in software development because software products are usually the realisation of strategy, so:

1. In order to properly and coherently create a software product you need to have a product strategy. You need to know how the product is going to make you money.

2. In order to have a coherent product strategy you need a coherent corporate strategy. Because the product is the implementation of your corporate strategy.

It doesn’t matter much if your local shop lacks a strategy. People still come and buy things, the shelves are restocked and people get paid. But if you have no strategy for your software why would people buy it? What good does it do them?

You might sell a few copies but without further development the product will rot and sales will dry up. Bugs will become apparent, new operating systems will appear, new applications will emerge that you need to interface to and competitors will match your features. Fail to answer these issues and people will stop buying your software. Things change whether you want to or not. And they change much faster in the software industry than in the corner shop industry.

So you need to move your software forward, keep it fresh, release new versions. And that means you need requirements. But you can only create requirements if you know what your company is trying to do. Otherwise you will end up filling you software with a bunch of features which seem like a good idea to someone but don’t add up to a coherent package.

Now as I said before, it is not enough to have corporate strategy, or even a product strategy. You need to have one that can be communicated and understood by everyone. And you need to actually communicate it and keep on communicating it. Part of the way you communicate it is through product features and updates.

So, you need people who’s job it is to turn that strategy into product features. Those are the people who need to have the ongoing dialogue with customers, the market and developers. These people may be called Product Owners, Business Analysts or Product Managers, what ever, someone has to decide what is in the product and the code developers are not the right people.

Now the difficult bit. Too many companies don’t have a strategy, or they have one they cannot, or will not, communicate. They fail to employ the people who will turn that strategy into reality. So it looks like they are busy but the people doing the coding are directionless.

If you want to play the software business game then don’t leave home unless you have:

        1. A strategy you understand
        2. People who can make it a reality

To do anything else means you are heading for a software failure.

Unfortunately very few software development books, courses and methods address these issues but I am convinced these problems lie at the heart of many, maybe most, software development failures.

Thoughts on strategy and software development

My last two blog entries, and some recent reading (I’ll write about it soon) have given me a lot of food for thought about business strategy and how it relates to software development. Fundamentally strategy is about knowing what you are doing, articulating what you are trying to do and using this understanding to drive what you do.

All companies have a strategy whether they realise it or not. I don’t expect many local shop owners spend their time thinking about strategy but they have one. For them strategy is mostly location, location, location. Open a shop in a good location and you will get trade. OK there is a little bit more to it, does the shop sell newspapers? fruit? ethnic foods? In the abstract these are issues of strategy but I expect each one is considered without the need to use the s-word.

This is what I think off as implicit strategy, these businesses have a strategy but it is not spoken about. This approach works - well it mostly works, provided little else changes they can carry on as it. However most of these business are small, one shop, maybe two. But, the more these business grows the greater the need to make the strategy explicit.

An explicit strategy is one that is stated and articulated. This means it can be shared and communicated. If you are going to expand beyond the ideas on the owner’s head then it is necessary to communicate so everyone can pursue the same aims.

Moving from implicit strategy to explicit strategy allows three things (at least) to happen:
• Strategy can be communicated and therefore shared so more people can be involved in the business
• Strategy can be analysed, therefore problems can be spotted and new opportunities can be found
• Strategy can be used to drive execution; so structures, processes and products can all be built to ensure the strategy is successful.

In other words strategy is about scale, it is about creating the conditions to grow.

Now we can return to software development... where exactly the same process happens occurs.

A programmer can have a great idea for a program, and like the shop owner, they can build it. They can stick it on the net and may even sell a few copies. As success grows they may want to hire more developers, thats where the software requires design, architecture and so on. Its about scaling. Once again it is about sharing the ideas and communicating them. It is about analysing the design, finding problems and creating the support infrastructure.

Just to be clear, I’ve said it before in other words: Software Design is equivalent to business strategy. It is about scaling up.

And as this software is success, and more programmers work on it money generation becomes more important. The first program sold because, like the local shop, it was in the right place at the right time, but to sell more copies, to pay for more programmers, you have to know what you are trying to do.

So the software is no longer just software, it is a business, and like all businesses it needs a strategy. And since this business is growing it needs to move from an implicit strategy to an explicit strategy - for all the reasons above and more. The software industry is highly competitive and international, things are always changing. If you don’t consider the changes, and how you will responded you won’t survive long.

Strategy matters more for software companies than to many others. This is because software, indeed all IT, is about change. You use IT (and therefore software) to create change. Either in your organisation or in your customers. You need to understand what kind of change you are creating, how you are creating it and why you are creating it. Organisations are in greatest need of strategy when change is in the air.

There are actually two strategy tracks in a software company, one embedded in the software design, and one stated as business strategy. The two are interlinked and can hinder each other. You cannot pursue a business strategy that your software architecture will not support, and you cannot expect a software design to work well if it runs against business strategy. We’re back to Conway’s Law but that is not my primary point here.

There are two problems I want to highlight. The first concerns strategy itself.

The trouble with strategy is that it is grand, it sounds grand and as the economist John Kay puts it strategy is a synonym for expensive. Consequently all too often strategy formulation becomes the work of ‘big brains’ in the company, or even outside consultants.

This excludes the bulk of the employees and this itself has two problems. First you miss out on their thinking and thus potentially miss out on new ideas and emergent strategies. Second once you have decided your strategy you need to communicate it. This isn’t trivial. Communicating a strategy means you have to be able to communicate it, then you need to actually communicate it, then you need to re-inforce the message and keep re-inforcing it. This takes time.

The second problem with strategy is that it doesn’t happen. Maybe we continue thinking like a small shop keeper: people keep buying our products so we don’t seen the need to rethink anything we do. Or perhaps we do rethink our strategy but perhaps we fail to communicate it. Perhaps only the ‘big brains’ know or understand the strategy.

And these problems are important when you are developing software. Because product requirements derive from the company strategy. If you don’t have a strategy, or you don’t have an strategy people know about and understand then you stand little chance of understanding what your software products should do.

Requirements: A dialogue not a document

I’m not a lover of requirements documentation. I’ve discussed this at length before - see Why Do Requirements Change? and The Documentation Myth. However requirements and even requirements documents do have a part to play in the development process. This fact has been brought home to me recently while working with ‘Requirements by Bullet Point’ and ‘Requirements by Project Name.’

These two conditions arise when people try to take short cuts with documentation. In the first case, Requirements by Bullet Point (RBBP), somebody lists ‘the obvious’ requirements, or the ‘things we all know’. In the second, Requirements by Project Name (RBPN), people come to believe the project name conveys all the requirements necessary, unfortunately, the same name tends to mean different things to different people.

What such requirements miss is that the devil is in the detail. Every line of code in a software product contains multiple decisions. A product with 10,000 lines of code contains millions of individual decisions. Some, many, of these decisions relate back to the requirements. When this information is not available the guys writing the code have to guess. When developers have to guess it is the business which suffers.

Agile development lends a whole new twist to the problem because it specifically sets out to deal with changing requirements. But some people believe this means you can start out with no requirements. In traditionally waterfall projects requirements came at the start so projects should not proceed without them. Thats the theory but in practice such projects also fall pray to RBBP or RBPN.

The problem isn’t helped by developers who believe requirements are not necessary, after all, developers know best. Occasionally this is true, normally it occurs with very technical products or where a developer is themselves an expert in the field. The danger is always that developers mistake what they want to do, or what they can do, with what needs doing. What needs doing (the requirements) always needs to be rooted in what the business or market wants and needs.

To make things worse requirements often play multiple roles in a project. Not only are they technical requirements but they are also part of a legal contract and a financial rewards (and penalties) system. When they are called on to fill these multiple roles things just get more complicated.

The problem is that requirements (and I extend this to include specifications here) are just plain difficult for all the reasons I outlined in Why Do Requirements Change? and The Documentation Myth and more.

I think the solution is to recognise that project requirements are an ongoing, evolving, entity. They are not written once and set in stone, they are a continuing process not an event. Or to put it another way, they are a Dialogue not a Document. And to have a dialogue you need multiple people. One of these people needs to be the owner of the requirements, these may be called the Product Manager, the Product Owner, a Manager or a Business Analyst.

The important point is there needs to be someone who is charged with having these dialogues and ensuring a consistent view emerges. Consistent doesn’t mean unchanging but it does mean it remains fairly stable and only changes when new facts or events emerge.

This person needs to be hold an ongoing dialogue with all the stake-holders: the customers, the end-users, the developers, the market, the wider organisation and even the software itself, by looking at it, evaluating it and looking at its competitors. Somebody needs to be charged with knowing what the product needs to be and articulating that view.

Requirements documents have a part to play too. The process of creating the document is an learning exercise for the product owner. In writing the document they are forced to research the subject and pull all their thoughts together in a logical order. For other people the document shows that somebody has done their due diligence and thought about the issues.

Unfortunately too many people in too many companies believe a static document, or RBBP, or RBPN or thought-transference is sufficient to get a software product created. Waterfall had it partly right in this respect, you need requirements to a project, you need to know what you are trying to do, but you need to constantly keep asking and re-asking that question and stating the answer.

Agile: Software and Strategy

One of the reoccurring themes of this blog is my belief that there are strong parallels between the creation of company strategy and the development of software. For a start both are intellectual exercises that produce abstract models. You cannot tell how successful either is until it is tested in use and both require large amount of intellectual thinking.

I also believe that many of the techniques used in software design and strategy formation can be successfully applied to both domains. Both domains can learn from the other.

And, to top it all, because so much business strategy is implemented through software I see software execution as a continuation of the strategy process.

Consequently I’m always on the look out for evidence to support this theory. This month I thought I had found some more evidence. An article in this months issue of the MIT Sloan Management Review entitled Closing the Gap Between Strategy and Execution by Donald Sull seems to support my case. In fact it seems the article has discovered many of the practices of Agile software development in the strategy formation and execution process, e.g.

• Use of iterations: plan some, do some, assess and re-plan;
  
• Use of commitment, or promises, over estimation
  
• A reflection process that sounds a lot like the Retrospectives we practice in software development.
  

So was this the missing link?

Unfortunately not, in this case it is hard to disentangle cause and effect. First of all you have to go back to the roots of the Agile software movement...

Agile development has its root in the Lean manufacturing movement, and in the “Quality if Free” ethos, and in business strategy itself.

The term Agile itself comes from the business domain, tracing backwards – and I haven’t tried very hard – the first reference I know about comes from Alistair Cockburn (Agile Software Development, 2002) who cites Goldman (Agile Competitors and Virtual Organizations, 1995).

Sometime in the 1990’s the idea of ‘Business Agility’ arose. This raises its head from time to time in business literature but only in software development does – as far as I know – it seem to have taken off. (I have a theory or two here and I’ll explore them in a future blog if I get the time.)

So this article builds on research into software development processes which are themselves in partly the result of reading the business literature. You see why I say cause and effect are hard to untangle?

In writing this blog I’ve looked up the Donald Sull’s web site and discovered a lots of mentions of “Strategic agility” and it seems he teaches a course on this at LBS. Which goes to prove that business Agility is alive and well and prospering in at least one business school.

Unfortunately the business agility community and the agile software community do not seem to have much cross over. This is where Sull’s article in the Sloan Review is interesting because he does mention software development. However he doesn’t mention Agile software development, neither does he fully reference the agile software development literature.

Sull cites Scrum as an example of how strategy formation might work, and how the “new rules” of strategy formation might be used. However, given that Scrum is Agile, and Agile has its roots in business is this reference circular?

To be honest, I think Sull has missed some points. As I just said I think he could have referenced the software development literature he cites, for an academic that strikes me as a little sloppy.

Secondly he proposes a strategy formation cycle of four steps: Make sense, Make choices, Make things happen and Make revisions. To me that looks a lot like Deming’s Plan, Do, Check, Act (PDCA) cycle.

I’m probably being picky here. The MIT Sloan Review is towards the popularist end of academic journals. It tries to contain articles that managers might actually read. Had Sull given us the full academic treatment (and he may well have done so elsewhere) the thing would be read a lot less.

So, where does all this leave us?

Well I take it as good news. Someone else is finding links between software development and business strategy, specifically in the Agile field of both subjects. This can only be good news if it brings the two domains a little closer. And personally I think this further validates my theory.

This may also show that the software development community are at the cutting edge of understanding how you actually go about doing agile anything. It is one thing to talk about an Agile strategy but how do you execute one? What do you actually do?

Big MacSwitch

Ten years after I gave up my last one, and after five years of lusting for another, I did it last week. I made the switch to a Mac – or back to back if you prefer.

During that time the Mac has moved from 68020 (I think) to PowerPC to Intel, and completely rewritten its OS so I was expecting something very different from what I last owned. So I’m surprised by how much is actually unchanged, Finder is still there, so is System settings and the short cut keys I learned as a student still work. But so much more has changed...

The challenge now is to adjust to MacSoftware. I ducked and bought Microsoft Office so I still have Word and Excel, I’ve installed Mac Firefox and Thunderbird, and I’ve bought Endnote for reference tracking; and I’ll buy more. But I’ve also given up a lot of software, Visio and BlogJet being the most notable ones.

I don’t know yet if I’ll give in and buy an emulator/virtualisation package, somehow that seems cheating. First I want to see if I can get genuine Mac software. A Mac replacement for BlogJet is top of my list. (Any recommendations?)

But much of this has to wait. Although my book is finished (the publisher even sent me mock ups of the cover this week!) I’m hard at work on the index. This has to be the most boring, uncreative, tedious aspect of writing the whole book.

At the moment doing anything with the Mac takes at least 10% longer than it did with my PC. I’ll hang in there because, and this is the reason I finally decided to move from Windows: there is no point in buying a new PC.

Yes I could buy a smaller machine, that would be good but is not enough alone. My 5 year old Compaq still has all the power I need so there was no point in a faster process or more disc space (plenty left). Although it was showing its age in other ways.

But if I bought a new machine I would either get Windows XP – no change there, and future software compatibility problems I guess – or I get Vista. Thing is Vista represents as big, or even bigger, change to the Windows UI than a Mac does. So I might as well take the pain on a machine I’ve been lusting over!

Book review: TSP - Coaching Development Teams

One of the little knows secrets of the ACCU is that members can get free books.  All you have to do in return is to write a review.  The review will be posted on in the ACCU book database on the website (available to anyone free of charge) and most likely (space permitted) included in an edition of CVu magazine.

Members can get a full lists of the books waiting for review from the website, and none members, well… think how much your £35 membership fee could save you.

As regular readers of this blog will know I’m very interested in the subject of coaching.  So I decided to review the latest book from Watts Humphrey (farther of the CMM) TSP: Coaching a Development Team.

The review will appear online soon and in CVU a little later, but for blog readers, well, you can have it early…

Coaching seems to be everywhere these days.  I know I've been banging on about it for a couple of years but I am not alone; Phran Ryder wrote about it in CVu last year; several of the Agile methodologies suggest a team coach; and the general press seem to cover business or life coaching every month.  Now the Software Engineering Institute at Carnegie Mellon University (yes, the people who brought you CMM and CMMI) have decided to jump on the bandwagon too.

I should perhaps state my bias up front.  Good stuff does come out of the SEI but my first reaction to anything they produce is scepticism.  I know this isn't good of me but I recognise the bias and try to compensate.  In reviewing this book I'm trying to be even handed.  And in truth, a lot of what does come form the SEI is well researched and thoughtful.

So to the book. This is one of many books from the SEI that covers the "Team Software Process" or TSP for short.  Now I don't know much about the TSP so in reviewing this book I was hoping to learn a lot about coaching development teams and a little about the TSP.  As it is I've learned a little about coaching development teams and a little about the TSP.

The book is completely true to its title.  Lets take it word by word:

• TSP: The book is TSP based, TSP runs through everything in the book.  I felt at a disadvantage because I don't know the TSP and this limited what I could get from the book.  Neither is it a book to learn TSP from.


• Coaching: it seems the TSP takes a very directive approach to coaching and assumes the coach is the TSP expert on the team.  Manager and developers look to the coach for help running the process and resolving process issues.


• Development: its about software development teams (who else would use TSP?)


• Teams: between the TSP advice there is good advice for team coaches.  Unfortunately the author tends to use more words then necessary.  The book could probably have been written in half the number of pages.

The feel the book is culturally biased towards large American corporations, maybe these are the only people who use TSP in which case it doesn't matter.  But if you are European, Indian or a small corporation I wonder if you will find the book so applicable.  Other than this the book is well written and the author knows his subject.

In summary this book is true to its title.  It is about coaching TSP teams.  If you are coaching another type of development team you will learn something here but there are other sources were you could learn more in fewer pages.  If you are coaching a TSP team you might well find this book very valuable. 

To the best of my knowledge nobody has yet written a good process-neutral book on coaching development teams.  In the mean time if you need to coach a team, and they are not following TSP, I suggest you read some of the more general books on management coaching. 

IT is from Mars, HR is from Venus

In general IT and Human Resource departments do not get on well together.  To be fair to IT I'm not sure any department in a company gets on brilliantly with HR but IT seems to get one worse than most.  I once worked for a company where one senior manager claimed "I only work for small companies, as soon as they get big enough to have an HR director I leave."  True to his word within a year of the firm appointing a permanent HR director he was gone.

When you look at it the two departments really are opposites.

• HR is generally staffed by people who use people skills, they do touchy-feely, they do form filling and the do structure.  HR comes along late in a company's life; nobody founds a firm by starting with an HR group.  HR is also, if we believe stereotypes, largely staffed by women.


• IT - and really I'm talking specifically about software development groups - are the reverse.  They are staffed by people who don't know the meaning of the word touch, generally dislike form filling (why fill in a form when you can create an electronic systems?) and are creative.  Software developers are often the first people in a start-up company.  And on the whole the teams are male dominated.

To be fair to HR - and I have been known to stand up for them in the past - they do have good intentions.  HR departments can be a force for good in a company and they do work that does need doing in big companies.  On the whole IT people do not appreciate this.  Which just goes to make the conflict so much worse.

I've commented on this subject before.  Then I gave two reasons: firstly that HR groups just do not understand IT and secondly that you actually need damn good HR people if they are to benefit IT. 

So why are software developers so different form the other groups HR works with?

Well I think there are some characteristics of development teams which alienates them from HR people.  Other groups and individuals have these characteristics but in software development they are more common and more pronounced:

• Technical skills are to the fore and social skills can be non-existent.  I think the developers of tomorrow need for more social skills than those of yesterday but still technical skills are key.  This is the opposite of HR departments themselves where social skills are more important than technical skills.






• Software developers often appear to job-hop.  A year here, two years there, six months there.  To a classical HR person this looks risky, will this person be with the company in three years?  But actually this can give a software developer a lot more experience than they would get from working on the same code base year after year.
  

  And it is not really developers' fault.  Much development work is project based, teams expand and contract, therefore people move teams and people move between companies to follow the projects.  Further more because so many software companies are start-ups the risk of company failure and redundancy is that much higher, it is an occupational risk.  Unlike HR departments which only exist in safe companies.

  
  

  The really odd bit is that the best developers may have the most fractured CVs.  If you are good you will be hunted.  If you are an average developer you are more likely to stay in one place because fewer people want you.  Simply good people move.  This is the opposite of what HR expect.  Part of this is because...

  
  
• Productivity varies:  good developers can be twice or ten times as productive as average developers.  In fact one study I saw put it as high as 27 times more productive.  Yet do you see this in their pay?  Many of us have met hyper-productive developers but have you ever met one who was paid twice or ten times more than the average one sitting next to him?
  

  These kind of difference mean that developers who are a little bit better than average can be significantly more productive.  Thus becomes more important to be able to differentiate between someone who is 10% better than average and someone who is 15%.

  
  

  As a result a good developer can consistently extract more economic-rent from an employer.  Because paying people these sorts of differentials is alien to HR groups they don't do it thereby leaving the gate open for someone else to.

  
  
• Software developers often lack traditional career markers: in other words they generally don't do sport.  They were never school team captain and - if they are like me - spent their teenage years in front of a computer honing their skills.  And they don't move up the career paths into management.  If you have a great developer then keep him developing, do not force him into management if he wants to carry on cutting code.

This is all leading up to one more difference.  The best software developers are clever, very very clever.  There is a scene in the BBC film "Breaking the Code" where someone from the Ministry of War tells Alan Turning "You are much more intelligent than most of the people around us.  That makes them very nervous."  I think that effect is at work too.

So what can be done?

There needs to be work on both sides.  HR needs to appreciate the special challenges and demands of managing IT resources and especially software developers.  IT needs to recognise how HR can help and the corporate need for HR.  But this may not be enough, we may need a structural solution.

A few months ago I visited the offices of one of the UK's leading national newspapers.  There are two sides to a newspaper: the business side, including production, advertising, marketing, accounts, etc. and then there is the editorial side.  Because of the need to keep editorial independent this needs to be handled by journalists.  Therefore, there needs to be two HR departments.  The first is for the bulk of the employees and the second is just for the journalists.

I suppose the main HR group could handle the routine admin like payroll, tracking holidays etc.  but to have journalists governed by the same management structure could compromise editorial independence.  So they have their own HR group, staffed with managers from the editorial side.

This model could work in IT.  I can imagine a new role inside the group "Technical HR manager".  This person would be involved with hiring, performance reviews, etc. etc. but they would know about technical people in depth.  They would come from a technical background themselves.

Although this might sound like a drastic change I think it is reasonable.  Companies which depend on software development really bet their future on their people.  They bet that their people can develop better technology than the competition.  What appears to be a technology based business is in fact a people based business.  There is vast difference between having above average people and above above average people.  Just go and ask Google or Microsoft.

Ironic isn't it?  HR departments can't be trusted when human resources are the most important thing.

And that's another thing, why on earth did we dump the name Personnel Department? We are not talking about some plug-compatible resources here, we are talking about people.  Living breathing people, not resources.

My guess is that Personnel Departments dumped the title so they could put themselves on a part with the money and machines, the other resources; in doing so they lost sight of their key differentiator.  When people are key you have to treat them as such.

I have an ISBN number!

OK I admit it, I do vanity searches.  I was at the Amazon website for something today and I did a vanity search.  The differences this was is: I was.

Changing Software Development: Learning to Become Agile is now listed as available for pre-order.  The other surprising thing is the publication date.  I was expecting January 2008 but it appears I’ll make 2007.

And if your interested the ISBN is 047051504X, or in the new 13–digit ISBN system: 978-0470515044.

I had better get on with the index then!

Back from EuroPLoP

I was out at EuroPLoP in Germany last week, and much of this week has been spent in recovery mode.  EuroPLoP is a great conference – or rather un-conference.  Unconference is an expression I first heard last year that describes a conference which is different.  EuroPLoP is certainly different.

EuroPLoP is first and foremost a pattern writers conference.  So we spend time reviewing peoples papers not listening to presentations.  We spend time playing games together.  Actually this bit is essential because it builds the community and helps you take the feedback in the reviews.

We also hold open ended discussions (focus groups), drink (free) beer and talk, talk, talk.  At breakfast, lunch, dinner, in-between and in the sauna.  Some of the best conversations are in the sauna.

Our conversations revolve around patterns, software development, teams, books, writing and, in my case, business models.  There are more and more patterns being written about business, it is only a matter of time before someone publishes the first book.

As an aside, one of the founders of the European Patterns movement, Frank Buschmann, was at EuroPLoP.  He mentioned some research he had seen about software engineering literature.  It seems that the most referenced software engineering book (not including text books) is…. Design patterns (aka “Gang of Four book”).

(Unfortunately I don’t have the reference to hand, I think it is Paul Clements and others from SEI at CMU.)

The second most references book is Pattern-Oriented Software Architecture Volume 1 "POSA 1" and "POSA 2" (Pattern-oriented Software Architecture Volume 2) also makes it into the Top-10. 

In fact 6 or 7 out of the top 10 books turn out to be pattern books.  To me that says Patterns are on to something. 

Unfortunately, all too many developers don’t know about patterns and those who do only know the 23 in the Gang of Four book, and of those 23 Singleton seems to be know more than any other.

The other news from EuroPLoP is about me!  The conference committee decided to make me conference chair for 2008 and 2009.  I have to admit I am a bit worried about the work involved and tried to avoid the post but I was persuaded. 

Wow, me, conference chair…. I can hardly believe it!