Deep thoughts and irony

I’m just putting the finishing touches to a new Requirements Dialogue Sheet for a trial run this week with some guinea pigs (see my Dialogue Sheets update blog last October for more about this). And something thought provoking has come up I want to share.

If you’ve seen my dialogue sheets you will know that around edges I place quotes: some humorous, thought provoking, some (hopefully) inspiring and a few all three! As I edit this sheet two quotes have come next to each other and it is making me thing.

From Sergey Brin, of Google fame:

"It's important not to overstate the benefits of ideas. Quite frankly, I know its kind of a romantic notion that you're just going to have this brilliant idea and then everything is going to be great. But the fact is that coming up with an idea is the least important part of creating something great. It has to be the right idea and have good taste, but the execution and delivery are what's key"

And from Leo Trotsky, of Russian revolution fame:

"Learning carries within itself certain dangers because out of necessity one has to learn from one's enemies."

Then add in another Trotsky quotes from his time as Commissar for Foreign Affairs:

"We will issue a few revolutionary proclamations to the peoples, and then shut up shop"

The interplay of the quotes interests me. (If only Trotsky had had Brin’s advice!)

For those who know a little about the history of these two men there is an added depth.

While you think about that, if anyone would like to volunteer to test one of the new requirements dialogue sheets please get in touch.

Xanpan book 2: The means of production

Today I start unveiling Xanpan book 2: The Means of Production - Managing team centric Agile Software Development.

Many regular readers will have read about Xanpan - my own blend of XP (Extreme Programming) and Kanban - and the most regular readers won’t need telling that the message behind Xanpan is…. Create your own development method!

But I’m not sure every reader has yet bought a copy of Xanpan. Xanpan is available in electronic form from LeanPub and in hard copy Xanpan is on Lulu. There are also some reviews of Xanpan on Lulu - and plenty of space for more.

Now its time to announce Xanpan book 2.

Xanpan book 2 is much further developed than I like to admit. In fact what I’m publishing today has been ready since before Christmas. But like so many others the desire to unveil a more complete product has held me back. The desire to do a more complete job has detered me. I’m just the same as everyone one else!

So, I’m taking a chance. I’m pushing some of it out there and let see what happens.

As with any LeanPub project lets see what the feedback says and then we’ll do some more.

Right now Xanpan2 contains the introduction and the first chapter “Teams Heuristics”. It also contains the chapter headings for the chapters I think will be in the book as it develops.

If you like Xanpan 2 please send me some feedback, and if you don’t like it please please send me some feedback. As always, the best feedback is money!

My intention is to polish and publish more of the chapters over the next few weeks and months, and try to complete the unfinished chapters too. As I do this I might push the price up!

I’ve got an idea where this book will end, when I get there and I’m happy I may decide to have it professionally copy edited. That is a batch process so much wait. And again I’ll push the price up.

Now: go get Xanpan book 2.

I hate bugs (A rant)

Rant on.

In software terms quality does not mean walnut dashboards, it does not mean gold plating, it does not mean polishing to perfection. These things may happen in a development team but they should not.

However you define quality for a piece of software I bet it has no place for “bugs.” In fact, I bet anyone who has actually written a definition of “what is software quality” included something like “Few or no bugs.”

What ever else “software quality” means it does mean producing largely bug-free code. The best performing teams can deliver on this. They may not be entirely bug free but they can be largely bug free.

When bugs are present, when quality is compromised, bugs appear. Customers are unhappy - they may loose money or terminate contracts. Or they may keep calling your support desk.

Bugs destroy predictability because they can appear at anytime and demand fixing.

Bugs destroy productivity because they disrupt work and take time to fix for little apparent gain.

Bugs destroy any hope of meeting schedules because nobody knows when the bug finding and fixing will be done.

Bugs and poor code quality hinder future work because developers find themselves battling past problems.

Compare this with developers who always work on new code, those who start with a new sheet each time, those who carry none of yesterday’s baggage. Developers who work on fresh prototypes will always look better than those who work on a legacy.

Bugs make it difficult, if not impossible, to have a rational conversation about “what to build next” because there are bugs to fix. Bugs discussions don’t add value because bugs don’t add value. The only value fixing a bug adds is putting value back that was missing in the first place.

Bugs make it difficult - no, impossible! - to have a rational conversation about delivery dates too because nobody believes the dates will be met.

And when you have lots of bugs developer, testers, requirements engineers and, most of all, managers, forget how to do their real jobs because so much of their time is taken up with bug conversations.

Yet techniques for combatting bugs do exist and are used by the best companies.

Code reviews are one of the most powerful techniques for removing bugs but when used in a low trust environment with confrontation they can descend into school yard bullying.

Test Driven Development (TDD) is an extremely powerful technique, one team at Microsoft recorded a 91% reduction in bugs. While many developers are now aware of TDD few actually practice it, and many of those who do practices it erratically or without real understanding.

To embed TDD in the culture required support: specifically technical coaching. This approach also helps address hidden skills deficiencies, e.g. poor use of object-oriented techniques. Technical coaching is expensive simply because it is one-on-one with developers.

Look, I happen to think TDD - and by extension cousin BDD - work. I know not everyone agrees with this, that is your right. I just ask: if you don’t believe TDD will help, what do you suggest? - just add your suggestion in the comments below.

A third technique is pair programming, while controversial and instinctively disliked by many programmers but can be highly productive.

These are not the only techniques. There are other, often complementary, techniques available - see my old “Things to do to improve code quality” blog.

I hate bugs but there is something I hate more than bugs: the attitude that tolerates bugs as “a fact of life, something that will always be, something we can’t do anything about.”

I don’t hate people who think they can create software quicker by tolerating bugs. I don’t hate them because they aren’t worth hating. They shouldn’t be in the industry. Quality software, few bugs, makes for shorter delivery cycles, lower costs and happier customers.

The attitude “Low quality is faster and cheaper” has no place in our industry. Anyone who believes this doesn’t deserve to work in the software industry.

One of the big problems I see with the software industry is that so many people have stopped aspiring to do anything better. The philosopher Aristotle is reported to have said: "Our problem is not that we aim to high and miss, but that we aim too low and hit”.

Most of all I hate the attitude that aims low with bugs and code quality.

Rant off.

(If you want a longer, more rational, discussion on how to deal with bugs have a look at the draft “Bug Management Strategies” chapter (PDF) for Xanpan book 2 which is available from my website. See also the appendix in Xanpan book 1.)

Retrospective Dialogue Sheets updates and changes

When I say changes, I’m not saying anything about changes to the sheets themselves. I mean I’ve been thinking about how I make the sheets available and I’m going to make two changes.

Firstly, I’m going to remove the print-on-demand service for the sheets. Second, I’m going to remove the need to register before downloading a sheet. You can still find all the sheets at DialogueSheets.com just now they will be a little harder to get and a little easier to get.

Now I’d like to explain why I’m making these changes.

I’ve always felt I needed to offer people the option to get printed sheets, hence the print on demand service. However, not many people use the service. I might have once thought I could make a little money off the service but I long ago gave up any dreams, it doesn’t get used enough to make me rich!

It seems most people either have large printers or get the sheets printed by their local print shop - I use Kall-Kwik myself.

To complicate matters, when it does make me a little money, the company which provides the service (Mimeo) send me a cheque. Or rather a check, against a US bank in US dollars. Since the sums are small the cheques cost more to cash then they are worth. This is a shame because when Lulu or LeanPub send me money - in dollars - they use PayPal which I can access easily.

Add to this the complexities of keeping the print-on-demand shop up to date and its just not worth it.

Second, the need to register.

When I first made the sheets available I really wanted feedback on who was using them, how they found them and so on. In the early days I would e-mail people and ask “What was your experience?”

That was like getting blood out of a stone. Very few people replied. Those who did gave me very useful feedback which allowed me to adjust the sheets and made me feel good.

I stopped this about the time InfoQ published my piece on Dialogue Sheets - three years ago, wow how time flies.

Since then there have been too many downloads to go ask for feedback - O, I could mail a few people but that requires work. Right now there have been over 1,300 registration in the last two years, and I known there were several thousand before then.

In the meantime a few people considered my request to register an imposition, I’ve had a couple of people tell me to my face. All I wanted was feedback but this put people off. I have on occasions given dialogue sheets away - they are part of the package when you buy a course of me but I also regularly give spare sheets away after conference presentations. When I do so I ask - no beg - people to send me feedback, but they rarely - no never - do.

I remember a man from the BBC who took a spare sheet at Agile Cambridge. He promised to send me feedback on what his team thought. I never heard from him again. I guess it went in the bin.

Maybe I’m a little bitter but actually, the point I’m trying to make is: its hard to get feedback!

I once planned to send a newsletter to everyone. But I never got around to it.

I once hoped a mailing list would take off, but it never did.

Probably if I had put more effort into any of those things they would have done better but as it is I think Dialogue Sheets are a success.

Thousands of downloads are a successes.

Popular articles in InfoQ and elsewhere are a success.

Conference sessions using the sheets are always well received - and I’m doing one again at DevWeek next month in London.

I sometimes meet people who know of me because of the sheets, that is a success.

And I get occasional e-mails telling me the sheets are being used and they are good.

Anyway, you have not tried them yet, give Dialogue Sheets a go in your next retrospective.