Software People Inspiring

Software Craftsmanship 2009 Follow-Up

This went out as an email to delegates, but is reproduced here for completeness

First of all, if you made it to SC2009 on Feb 26th then a big hearty thanks for helping to make the day the success that your generous feedback suggests it was.



An especially big thanks goes to everyone who ran the sessions. Your hard work is much appreciated.

Also, many, many thanks to Robin Doran from BBC Backstage, Peter Camfield from BBC Worldwide and Kerry Jones from BBC Future Media & Technology for all your invaluable assistance in putting the event together. Thanks, too, to all the BBC delegates who helped out on the day. You did a sterling job.

The event was very generously sponsored by BBC Worldwide and BBC Backstage. You should check them out, 'cause they're doing some pretty cool stuff these days:

http://backstage.bbc.co.uk

http://www.bbcworldwide.com

A few announcements:

* Were you at Keith Braithwaite's excellent TDD As If You Meant It? session? Do you still have a copy of the code you worked on? If the answer is Yes, then you might want to consider donating it to science! Please send zipped-up copies of your code to Dr Sue Black from University of Westminster so she and Steve Counsell from Brunel University can perform deranged experiments on it that hopefully will produce further insights into software maintainability.

* Don't forget to pay a visit to Sue's website dedicated to Saving Bletchley Park and see if you can help.

* A reminder about the upcoming Software Practice Advancement conference, which is being held in London this year at the BCS offices in Covent Garden starting on April 5th. I'm running a session on scaling up design reviews using automated code analysis. Apart from that, the rest of the programme looks pretty good, though ;-)

* Another reminder about Rachel Davies' Agile coaches gathering event which is being held at Bletchley Park on 22-23rd May

Following up:

Session Materials/Outputs

Immo Huneke has posted the outputs from his excellent and intimate session on My Favourite Keyboard Shortcuts on the - now publicly accessible - conference Wiki:

http://softwarecraftsmanship.wikidot.com/myfavouritekeyboardshortcutsoutputs

Gojko Adzic has posted slides and related material from his well-received session on Specification Workshops:

http://gojko.net/2009/02/27/links-and-slides-from-the-specifications-workshops-talk-at-the-software-craftsmanship-conference

Nat Pryce's notes for his fascinating session on Testing Asynchronous Systems can be find here:

http://www.natpryce.com/articles/000755.html

Ivan Sanchez posts his session materials for 5 Reasons To Have Coding Dojo here:

http://isanchez.net/2009/03/04/links-and-slides-from-my-session-at-the-software-craftsmanship-2009/

Feedback from the Blogosphere

Kerry Buckley very nicely summarises some of the sessions:

http://www.kerrybuckley.org/2009/03/02/software-craftsmanship-2009/

Gojko Adzic's great write-up of TDD As If You Meant It:

http://gojko.net/2009/02/27/thought-provoking-tdd-exercise-at-the-software-craftsmanship-conference/

Markus Gaertner's summary of the conference:

http://blog.shino.de/index.php?/archives/33-Software-Craftsmanship-conference-wrap-up.html

Diego Pino shares his thoughts here:

http://blogs.igalia.com/dpino/?p=22

Richard Fennell gets his thoughts down on virtual paper:

http://blogs.blackmarble.co.uk/blogs/rfennell/archive/2009/02/26/intent-is-the-key-thoughts-on-the-way-home-form-software-craftsmanship-2009.aspx

BBC Worldwide's Rob Bowley blogs about SC2009 and posts a great pic that illustrates how busy lunch was!

http://blog.robbowley.net/2009/02/28/software-craftsmanship-2009-round-up/

.NET journeyman Tim Ross posts:

http://timross.wordpress.com/2009/02/27/software-craftsmanship-2009/

SC2009 Vox Pops video

What Next?

Will there be a Software Craftsmanship 2010 conference? Very probably, yes. Watch my blog for developments, and get your thinking caps on for session ideas.

Where do we continue this dialogue? A good start would be to sign up for the Software Craftsmanship Google Group. Many of the folk you might have met on feb 26th are known to frequent the Extreme Tuesday Club in London. Also, you'll find us at Software Practice Advancement, XPDay and many other Agile-leaning events.

What about a specific regular meet-up on Software Craftsmanship? Bingo! Great idea. What a clever fellow you are for suggesting it :-) Yes, we shouldn't let the energy and momentum we gathered at SC2009 fixxle out, so I'm going to propose a regular meeting that will be a sort of mini-SC2009 where we specifically meet-up with our laptops for hands-on learning, sharing, practice and alcohol. (The four major food groups, I think you'll find.) The XTC venue is too noisy, really. So I'll be seeking out a friendly venue with a decent-sized function room and maybe even a projector and screen. I'm also leaning very heavily towards a weekend timeslot, because my brain is usually pretty frazzled by 7pm on a weekday! Keep an eye on my blog, and on the Google group, for announcements very soon.

I'm sure I've forgotten something, but isn't that always the way. Drop me a line with any thoughts, complaints or offers of easy money.

Software Craftsmanship 2009 - Conference In Development

First the good news.

I'm in the process of launching a new conference here in sunny old London Town (or "Larndarn Tarn", if you happen to have been born here).

I can't give away too much just yet, because:

a. There's not that much to give away, and
2. There's many a slip twixt cup and lip, and there's always the danger of these things falling through

But I can tell you that the working title for the conference is Software Craftsmanship 2009.

And I can tell you that the focus is going to be on the "hard skills" that take years to master. You know, the actual craft of writing good software. OO design, test-driven development, refactoring, build automation, architecture, patterns, code generation, modeling, concurrent and distributed programming. That sort of thing. Certainly there won't be any sessions about yet more things you can do with coloured bits of card and lego. Well, not unless anyone's discovered a way to generate working code from them.

I can also tell you that we have a provisional date and a provisionally booked venue. The provisional date is February 26th 2009. I'm not going to reveal the venue just yet, though. But it will be in London, rest assured.

Finally, I can tell you that the program selection committe is already starting to shape up very nicely indeed. And the invites are still going out, so we're looking forward to a very healthy pool of world-class expertise to help pick the final schedule.

Keep your eyes peeled for more information posted on this blog, or join my Yahoo! group for announcements.

An informal request for session proposals will be going out in about a week's time. Email me if you'd like to be included in this mailing.

Writing Thread-safe Code - What Can Go Wrong With Multithreaded Logic?

I've been getting a good deal of encouragement to talk about multithreaded programming some more, as it seems to be an area of great technical interest to many of you out there in developerland.

It's also quite obviously an area of some considerable pain...

I want to talk about two specific kinds of things that can go wrong when two or more threads of execution start interacting with the same data and objects:

1. The pre-condition paradox

Jill and John have a joint bank account with a balance of $100. (They're not big earners, I should stress. Probably teachers. Or nurses.)

Jill sees a pair of shoes she really likes in a shop window during her lunch hour. She calls her bank's 24-hour telephone banking service to check the balance of the account to see if she has the $75 needed to pay for the shoes.

Meanwhile, John spies a boxed set of Battlestar Galactica Series 4 (though, as it turns out, it's only the first 10 episodes of series 4, the cheating buggers!) He stops at an ATM to check the account balance to see if there's enough in there to cover the $40 he needs to buy the DVDs.

Both Jill and John see that the account balance is $100. But in the time it takes John to get from the ATM back to the DVD store, Jill has already used her debit card to pay for the shoes. So when John hands his card over to the cashier, the account now only has $25 in it.

His card is rejected, in front of a huge queue of shoppers who are all in the kind of hurry that only lunchtime shoppers can be in. He gets egg on his face, and leaves with the shame of knowing that everyone in that store thinks he's a no-good bum. Which, of course, he is - I mean, what kind of person buys Battlestar Galactica box sets when he's only got $100 left in his account?

But anyway, I digress. The point is that because Jill and John both interacted with the account concurrently, it was possible for Jill's transaction to break the pre-condition of John's transaction after John had checked that the pre-condition for his transaction was satisfied.

One way for Jill and John to avoid this kind of scenario would be if one of them could obtain exclusive access to the account until their transaction - the whole transaction, starting with checking the account balance - is complete. This would mean, in effect, obtaining a temporary lock on the account until the transaction ended. Jill gets the lock first, and so John has to wait until her payment for the shoes has cleared before he can access the account, by which time the balance has changed and his pre-condition will fail when he checks it.

In reality, Jill and John probably wouldn't need to access the joint account at the same except on rare occasions. So locking the account and forcing the other account holder to wait would be a viable option from a performance perspective.

But if many people were trying to access the same account throughout the day - perhaps a large organisation with multiple branches all sharing a single bank account - then the time spent waiting for the account to become unlocked might be very noticeable.

2. Deadlocks

Jill, having blown most of their balance on a pair of shoes, calls her Mom and asks if she can wire her some money. A funds transfer between two bank accounts requires a lock on both of them.

Mom's bank locks her account and then asks Jill's bank to lock Jill's account. Safe as houses, yes?

In the meantime, though, John has been speaking to Dad (who shares a joint account with Mom), and cooked up a similar plan (he's got his eye on a remote-controlled Dalek now, you see). Dad's bank also needs a lock on both accounts. But this time his bank asks John's bank to lock John's account first, and then to lock Dad's.

It could happen that while Mom gets a lock on Mom and dad's joint account, Dad gets a lock on John and Jill's joint account. Now each has to wait for the other person to unlock the other account. And they'll be waiting indefinitely, because Mom can't proceed until John and Jill's account is unlocked, and Dad can't proceed until his and Mom's account is unlocked.

A few simple strategies could have prevented this deadlock:

a. Lock shared objects/data in the same order

If Mom and Dad's bank had both asked to lock their joint account first, the deadlock could not have happened because Dad would have had to wait until Mom was done with both accounts before proceeding.

b. Lock shared objects/data in a single atomic step

If you need both acconts to execute a transfer, then lock both accounts at the same time and make all other threads wait before they can try to get a lock on any of them.

c. Timeout

If a thread has been waiting to long to get a lock on an object or piece of data, have it release all of its locked objects/data in case that's what another deadlocked thread has been waiting for.

One thing I'm putting though into now is how one might use automated tests (or other lightweight QA techniques) to describe multithreaded correctness and detect mutli-threading defects.