Software People Inspiring

First Auditions For Software Craftsmanship 2010 Point The Way

 

2010 brings a winter wonderland to much of Europe, and the first good auditions for Software Craftsmanship 2010 have been carried in on those freezing cold arctic winds.
David Laing has sent me a link to an already pretty slick-looking session on TDD for databases, which touches on lots of great stuff and utilises a good range of test and build expertise which I personally need to get my head around.



Emmanuel Gaillot has submitted a very interesting demonstration of the Robozzle kata in Haskell (not, I suspect, the last Haskell audition we'll see). A very good audition which I'm confident will translate into a great session.

Robozzle Kata in Haskell from Emmanuel Gaillot on Vimeo.

At this stage, formal auditions have not begun, except for coaches, but I very strongly recommend sticking your videos up and getting early informal feedback, as David and Emmanuel have demonstrated brilliantly here.

The SC2010 community site should be up and running in early February, and you will be able to join, submit links to your audition videos and vote on the other auditions posted and give feedback. Auditions will run through February to May, and you will be able to rehearse and refine and resubmit your auditions as many times as you like during that period before the final votes are counted and selections are made for the conference.

If you're interested in coaching a handful of auditionees each month to help them improve their sessions (and can spare 5-10 hrs/month), then I still have room for 2-3 more of you lovely, generous folk to lend a hand. In the spirit of egalitarianism, everybody must audition, including coaches. You don't need to be a master software craftsman, just confident that you know sh*t from shinola when it comes to practices like TDD and refactoring. Coach auditions need to be with me before February. 20 minutes of basic TDD or a bit of refactoring would easily suffice. Email links to auditions here. Coaches will get major kudos and a goody bag, and I doubt it'll look to shabby on your CV that you were an official coach at Software Craftsmanship 2010.

Keep those auditions coming!

FizzBuzz Java TDD Example Feedback

 

Just got a free moment before Zebedee tells me it's "time for bed" to post some feedback on my TDD illustration/example audition in Java/Eclipse:

I watched your presentation at http://www.parlezuml.com/tutorials/agilejava/fizzbuzz/fizzbuzz.html and here are some things that I found interesting about your style of TDD:

- The couple of mistakes you made (breaking test, infinite loop, 99 being Buzz) were useful to show how TDD finds problems, whether you made those mistakes deliberately or not. Having such things deliberately in a real presentation can be useful.

- It was refreshing to see the numberIsDivisibleBy method, because some time ago at StackOverflow I had done exactly the same and many people commented against it. :) See http://stackoverflow.com/questions/1060366/how-long-should-it-take-a-senior-developer-to-solve-fizzbuzz-during-an-interview/1060857#1060857 In my case, the code smell which triggered that refactoring was the additional parantheses in "if (number % (3 * 5) == 0)".

- I would not have created the *OneHundred method, since the parameterized method already expresses the intent and reads the same.

- Your style of writing tests is what I call "tests as examples" (or xUnit style). In order for somebody to find out what your FizzBuzz program does by reading the tests, he will need to read all the tests and reverse-engineer that why both 3 and 6 return Fizz (it becomes like an IQ test). The tests do not directly say that multiples of 3 will be Fizz.

The style of writing tests that I use, is what I call "tests as specification" (or BDD style). By reading just the names of the tests, it should be possible to understand the logic of the component under test. Even if somebody would give you only the test names ("the specification"), you could write the necessary test and implementation code and get the same result.

See the above StackOverflow link for how I named the tests for FizzBuzz. (Also I use underscores in the tests names for readability, as mentioned at http://www.infoq.com/presentations/10-Ways-to-Better-Code-Neal-Ford) For a non-trivial example of how I organize my tests, see http://github.com/orfjackal/tdd-tetris-tutorial (the "beyond" branch contains the most complete code).

-- Esko Luontola
www.orfjackal.net


Esko makes an interesting point about Behaviour-driven Development vs. vanilla TDD. The missing link here is triangulation. Namely that you may use more than one example to lead you towards a generalisation of a single behaviour. If you have more than one test for the same behaviour, you need a way to distinguish them in the test names.

You can also get into difficulties describing complex scenarios in abstract terms. I have some prior form in this, since I've applied formal specification techniques where we try to do exactly that. But people tend to understand things better from the bottom up, by wrapping their minds around a range of concrete examples, from which they can build a more abstract and sophisticated mental model.

Catalysis demonstrates this principle very powerfully in the modeling/UML world by using instance diagrams and filmstrips to explore examples before generalising to class models and the like.

Having done TDD and BDD, I have some personal insights into what works best for me. There's no right or wrong here. If you deliver better code and find BDD-style tests easier to follow, then fill your boots.

Marketing Codemanship: What Search Terms Do I Pick?

 

I recently got about $50 of free Google AdWords vouchers to help promote my company web site, codemanship.com. Yay!

Only, not so yay... You see, I've stumbled across something of a puzzle. I don't - repeat, DO NOT - want to tout myself as an "Agile Coach", or indeed, an "Agile" anything. Because, when I use that word - even just in passing - I immediately get pigeonholed by clients as a Scrum Master. Happens every time. And that's not business that particularly interests me, but it's a tough expectation to break once the perception's been established.

But if I'm not selling Agile coaching, then what, exactly, am I selling? And this is my puzzle. What keywords could I choose to have my Google ad appear when IT or development managers search on them looking for my kind of services?

Would an IT manager search for "software craftsmanship"? Very doubtful. Indeed, these days very few people are searching for "software craftsmanship". I know this because the SC2009 web site ranks second in Google's search results for that phrase, and my web stats tell me interest via search engines is very, very small compared to, for example, "use cases".

So I'm a bit stuck as to what keywords I should hang my hat on here. If a company's software/systems are poorly crafted - unreliable, untested, untestable, overly complex, hard to fathom, riddled with duplication and the worst kinds of dependencies - how could I use search engine advertising to find my quarry? Indeed, would a budget holder ever be actively seeking what I'm offering?

RFP for Software Crapmanship 2009

 

In recent years, thanks to the efforts of people like Robert "Uncle Steve" Martin, Kent "Cousin Daisy" Beck and Martin "Martin Fowler" Fowler, code is getting better. It's been getting more reliable, more streamlined and - most worryingly - more maintainable.

If the trend continues our gravy train is in very real danger of being permanently derailed. For decades we have enjoyed the fruits of our crappiness. Badly cut code, riddled with duplication, redundancy, unmanaged dependencies and other kinds of income-protecting complexity has ensured a continuous and bounteous income stream for the jobbing software hack.

We at the Institute of Mortgage-driven Development are working tirelessly to stem the growing tide of simplicity and readability that threatens to turn our once endless stream of money-for-old-rope off at the source.

To this end, we are organising the first international conference dedicated to the principles and practices that decades of experience have taught us leads to crappy, unmaintainable software.

Although an exact date and venue has yet to be selected, we want to give you this early opportunity to help set the direction of the conference by submitting session proposals and papers for our consideration.

Software Crapmanship 2009 will be held in the autumn, almost certainly somewhere in London. Although we can't say at this point precisely what kind of venue will be chosen, we are certain that alcoholic beverages will be served on the premises, and that - to ensure you don't miss out on those all-important billable hours - will be held in the evening. Registration will probably cost £10 on the door, and all profits will go to the Bletchley Park Trust.

Sessions will be limited to 20 minutes in length to cater for short attention spans. Sessions involving Ruby and/or naked or scantily-clad ladies will not be considered.

You can submit your session abstracts to info@softwarecrapmanship.org

Join us and together we can keep code crappy


Software Crapmanship 2009 is a Boffoonery production

Screen Captures Hold Key To Raising Your Game

 

I've been experimenting with techniques to help us assess how effectively we apply good habits, and one technique in particular seems to be bearing early and very promising fruit.

Inspired by the example being set by Antony Marcano and Andy Palmer's pairwith.us project, I've been using screen captures to assess how well developers - myself included - apply basic Test-driven Development practices on short coding exercises.

Here's how we've been doing it:

Agree a set of no more than a dozen good TDD habits. These must be simple and enforceable (i.e., it is relatively easy to know when you're not doing them). They could be things like:

* Write the test assertion first and work backwards

* Make sure the test fails for the right reason(s) before you try to pass it

* Don't refactor when there are failing tests

* Refactor out any duplicate code after passing each test

And so on.

Your list of good habits should roughly represent what you (and your peers, if you're doing this in groups) believe is "good basic test-driven development".

What we want to know is, given a sufficiently representative amount of code to produce, how often do you break these good habits? How often do you catch yourself doing little refactorings when you should be just trying to pass a failing test? How often do you leave duplicate code after passing a test? How often do you forget to check that the test actually fails for the reasons you would want or expect it to?

The answer, if my own experience is anything to go by, is more often than you think.

Pick a simple coding problem. Here's a good sample one: write some code that will generate the Fibonacci Sequence of a specified length (e.g., when the length specified is 10, it must generate {0, 1, 1, 2, 3, 5, 8, 13, 21, 34}), where the minimum length allowed is 8 and the maximum length is 50.

That takes most programmers about 30-60 minutes to do using TDD. Using a screen capture tool like Camtasia or CamStudio, record yourself doing this exercise. If you're a fan of the pomodoro style of working, then you can break it into 25 minute recording blocks. Give yourself an hour (or two 25 min blocks) to complete the exercise.

When you've finished, take a break to help refresh your mind and then sit down with a pencil and a piece of paper on which you've listed all the good TDD habits you wish to assess yourself on. Watch the screen recordings back. Watch them very carefully indeed.

Every time you catch yourself breaking one of the habits, put a big X against that habit, and note the time at which you spotted it in the recording and note briefly what you caught yourself doing (or not doing, as the case may be).

Your aim should be to get less than 3 crosses in any hour of programming. It's 3 strikes and you're out, basically. I like to follow the "shoplifter rule". Wait until they have tried to leave the store before apprehending them. If the programmer does a refactoring and doesn't immediately run the tests afterwards, wait until they move on (e.g., to another test) before giving them an X.

If you're doing this in a peer group, then you can asses each other's screen recordings. And you can also vary the exercises and increase the length or the number of hours to make it even more of a challenge. A peer group in one of my clients will be doing 3 hours - in one of which they'll program in pairs and assess each other in pairs, and BOTH programmers get a X each if the pair slips up, meaning that the navigator really has to stop the driver from making mistakes.

Doing assessments is also great practice for pair programming, especially if the screen recording is captured without any audio. With just video, assessors have only the code to go on, which is a bit like a pair programming situation without talking or any other kind of communication. The driver must say what they have to say through the medium of code, making it clear enough that the assessor can understand what it is they're trying to do, and the assessor must concentrate and follow the rhythm of the TDD process so they can clearly see when they are at red light, green light or should be refactoring.

It might even be possible to do a kind of mutation testing by showing assessors a screen recording in which a variety of deliberate small mistakes are made to see how many they pick up on. You have to watch the code like a hawk, believe me!

As with all of these things, there's a bit more to it than I'm able to explain here. In the true spirit of software craftsmanship, you really have to see it to understand it. And you have to do it to really understand it.

The early results have been very exciting, though. It's becoming clear to me that this requires a level of concentration and focus on good practice that is head and shoulders above certainly what I thought was "rigorous" this time two years ago. And the results also strongly suggest that knowledge and cramming don't help. It's all about the habits. If you're not in the habit of doing these things, then at some point you'll slip up.

Which is why it certainly looks as though you need months of regular, focused practice - a few hours a week - to reach a point where you will be able to do 2-3 or more hours of solid TDD to the kind of standard this exercise demands.

It's all about increasing self-awareness. By examining closely what we do and how we do it, we tend to notice all sorts of little (and sometimes big) areas that need improving that might otherwise have gone unnoticed. It's a bit like practicing in front of a mirror for dancers. To do things right, they really need to get a clear view of themselves doing it.

The groups I'm working with now will soon be graduating on to "basic" refactoring - though, as I look more and more at what they'll be doing, they'll still be taking refactoring to a level very few people have mastered. Exciting times!

Software Craftsmanship 2010 Straw Poll

 

The long and windy road to Software Craftsmanship 2010 starts here with a couple of questions that you, dear reader, can help us resolve.

For a whole host of very good reasons, the current front runner for next year's venue is Bletchley Park. I hear it worked out very nicely for the recent Agile Coaches Gathering organised by Rachel Davies and chums. The question is; if we held it at Bletchley Park (just a 45 minute hop by train from Euston, and then a 3 minute walk from Bletchley station), would you come?



The next question is about money. Thanks to the very generous sponsorship and hospitality of BBC Worldwide and BBC Backstage, we were able to put together a fairly cheap - but decidedly cheerful - event this last February. SC2010 is going to need a bigger budget so that we can do some of the really cool things that were beyond our reach last time and put together a truly great event. This would mean that we'll be asking for a small contribution to the coffers from your good and kind and generously lovely (but not in a sexual way) dear self - somewhere between 50 to 100 of your Earth pounds. To give you an idea, the Agile Coaches Gathering was 75 quid, and bloody good value at that.



Many thanks for your time, and mind how you go, squire!

Codemanship Is Coming

 

Those of you whose hobbies include typing in infinite numbers of random domain names into your browser and seeing what web sites come up may have noticed that this blog is now the holding page for www.codemanship.com

I'm going to be building a new family of ideas and services around the Codemanship brand, and like all good families, we already have a motto:

Curo. Cognosco. Factito. Communico.

"To care. To learn. To practice. To share."

SPA2009, SC2010, Carpool & General Nonsense

 

Just a quick post today with a few honourable mentions.

Firstly, SPA2009; with all sorts of stuff going on at the moment, I only managed to make it to one afternoon yesterday, which is a shame because it looked liked it was going swimmingly. SPA's a much more sophisticated affair than SC2009 was (though cheap and cheerful has its place, I should add), and hats off to the organisers for putting it all together. I'm due to be in town later this afternoon, so maybe I'll try and hook up with a few folk after the conference for a beer.

My own session at SPA was fun, but poorly attended, I'm afraid. I enjoyed it, anyway. And that's all that matters, I s'pose :-)

You can view a Flash demo of the practical elements of the session by clicking here. Alas, what you will have missed out on is the experienced insights of people like Alan Wills, Dave Cleal and Mark Dalgarno at the session itself. But I'm sure you'll get the jist of it.

On the subject of Flash demos, I just checked my stats on Libsyn and it looks like the TDD in C# demo has now been viewed 3,000 times. Which is nice. Remind me to do a Java version soon.

Finally, a quick mention about next year's Software Craftsmanship conference.

It's on.

In exactly what form remains to be seen, but I'm committed. And if I'm committed, that means it's happening. Even if it's happening in my flat. I can't tell you too much at this early stage, because there are lots of decisions that need to made, alliances that need to be brokered and sexual favours that need to be administered to make a conference possible. What I can tell you is this:

1. I'm banning talks, presentations or any other kind of session that doesn't involve real live coding. The feedback has been very clear about this; the best bit was getting a bunch of smart, talented and skilled developers around some code and talking turkey with real, concrete examples. I was impressed by how powerful that simple act can be when I used to take teams into a room with a laptop and a projector for a week or two and we'd take turns at the keyboard implementing solutions to real requirements. It's a great way to bring everybody to the same page quickly and with a lot less blah blah blah. And I feel very strongly now that this is the way forward for SC2010 and hopefully beyond. Let the code do the talking!

2. We're going to sort out network access, source control and other technical stuff this time around, so hopefully the first twenty minutes of your session won't be taken up with folk handing memory sticks around. We'll also keep copies of all the code that gets created, which will be donated to medical science for their secret occult experiments. Or something like that.

And while we're on the subject of software craftsmanship, in answer to one Tweeter's question - no, not everybody who promotes craftsmanship necessarily thinks they're a "master craftsman". Far from it, in fact. Don't be bullied by this sort of anti-craftsmanship rhetoric. If you go out there and push the craftsmanship message, you are doing a good thing. It doesn't make you arrogant or elitist. It does mean that you care, and that you at least aspire to high standards. Any negativity or animosity some people might voice about this nascent movement, I suspect, says more about the naysayers than it does about the size of your ego.

My ego, of course, is massive and I do - as the same Tweeter kindly pointed out in a private message to me - have a very high opinion of myself. And why not? I still hold the self-endowed title of "World's Greatest Software Developer" and nobody has challenged me for it yet. I am also a brilliant rock guitar player, Kung Fu fighter and I'm fantastic in bed. But that has nothing to do with my support of software craftsmanship. I'm just a big-headed gobshite who just happens to care about software development. I'm perfectly comfortable with that. Hey, it works for me :-)

Anyhoo, I'm off to watch this week's Carpool (highly recommended, by the way) before I launch into some actual work. Toodle-pip!

SPA2009 Session Practical - Scalable.NET Design Reviews Using Automated Code Analysis

 

If you can't make it to Software Practice Advancement 2009 this afternoon (or of you did make it and you want a reminder), here's a Flash movie of the practical elements of the session created in advance using the indispensible Camtasia Studio.

The thrust of my argument - because my arguments tend to thrust, dontcha know - is that code/design inspections are a form of testing, and when we do testing manually it's very labour intensive and doesn't scale cost effectively. For the exact same reasons that we automate functional tests, we should aim to automate our design/code quality tests as much as possible so that we can spot problems early and deal with them cost-effectively.

One thing we'll probably discuss is how we tackle design/code quality in an Agile, Scrum-like process. Well, if we're doing TDD, then I would suggest beng test-driven about it might work best. Along with your user stories, you could write "quality stories", like "As a design authority, I require that methods are kept short so that they're easier to test and easier to understand" and then developers could stick that in the backlog and champion it's inclusion in iteration planning*. When someone picks up that quality story, they could go to the design authority and agree acceptance tests - and this is where our automated analysis comes in. We could use a tool like NDepend to detect long methods, and if they fall outside of an agreed tolerance we could raise the alarm almost as soon as a method grows too big. Maybe it makes the buid fail. Maybe we have to refactor it there and then to get the build green again. Well, a man can dream, can't he?!

The examples use NDepend, but the principles can be applied using a whole bunch of tools that focus on a whole bunch of different aspects of design quality.




* And yes, I know giving the customer the choice will almost certainly mean that no quality stories ever get scheduled. In which case a portion of the budget should be controlled by the developers (e.g., 20%) so they can make sure at least some of it gets done.

My Lovely But Still Overdue SC2009 Summary

 

So I finally got around to following up on last week's amazing Software Craftsmanship conference. With the formalities out of the way, I just wanted to add some personal notes about the experience, because that - apparantly - is what blogs are for.



First of all, I just want to go on record and say that I got a real kick out of organising this conference. I had some great help from Peter Camfield, Kerry Jones, Robin Doran and many others that meant that pretty much everything went smoothly on the day. It was an absolute pleasure to put together, and hearing the very positive - some might even dare to say "gushing" feedback on and after the day was the icing on the cake.

I was really chuffed with the programme we ended up with, and - contrary to how it almost always works - doubly chuffed to see expectations being exceeded in the execution of those sessions. I think we got a kick-arse, A1 bunch of sessions and session leaders, personally. I couldn't have wished for a better start to what may well turn into a new series of conferences and other related events.

Talking of feedback, I really, really think we're on to something here. Software craftsmanship is not a flash in the pan, I suspect. It's not just Le Fad De Jeur. Being surrounded by 100 committed professionals who genuinely care about what they're doing and who are 100% dedicated to learning and improving has been one of the highlights of my checkered programming career. I want more!

And I'm going to get it! SC2010 is definitely on the cards now, and I'm feeling very confident about pushing the envelope next year and taking this conference boldy to places where no conference has been before.

But 2010 is still a loooooong way aways yet. SC2009 had a palpable energy and momentum. You can feel it when you watch the Vox Pops video. And a sentiment that came out in much of the feedback I heard on the day is "let's make sure this doesn't fizzle out". So I'm looking with some urgency into setting up a regular get-together here in London where we can get hands on together, run dojos and katas over a coffee or a beer. Frankly there's been too much lips-flapping and not enough key-bashing of late, and we need more opportunities to - as Frank Zappa so eloquently put it - Shut Up And Play Our Guitars!

But London's just one little part of the world where craftsmanship has caught fire. There are other flames being fanned in far-flung places like Chicago, for example. Ironic that in a city named after their politician's empty rhetoric (the "windy city") we have a strong and rapidly maturing tradition of software craftsmanship growing thanks to folk like Micah Martin at 8th Light, Dave Hoover at Obtiva and - lest we forget - Uncle Bob Martin and Mike Feathers at Object Mentor. Micah crossed the pond especially for SC2009, I'm told, keen to see what's going down here in London. I'm equally keen to forge links with craftsman in Chicago and wherever else in the world they may be found.

In these days of global warming and rising fuel costs, though, we should look for ways to achieve rich international collaboration and sharing through technologies like Skype, desktop sharing, videoconferencing and atomic carrier pigeons (okay, I may have made that last one up). Hopping on planes and seeing folk in the flesh is going to be a necessity, I'm sure. But it's not a scalable or sustainable route to the level of sharing that I think we're going to need to really drive craftsmanship forward across borders.

On a totally personal note, it was very refreshing to see the "A" word taking a back seat at a conference for once. sure, lots of Agile folk there and lots of Agile practices, but the word that dominated the day was "craftsmanship" - which is as it should be now.

So, my summary summarised - By Jingo, I Think We May Be On To Something, Here!

Well, that's enough superlatives for one day. I'm off to read a whitepaper on some Model-driven Architecture nonsense.
Until next week, toodle pip!