Software People Inspiring

Its Not How Fast we Deliver, It's How Fast We Learn

 

Just a little thought experiment for ya.

Split the room into 2 teams. (Yes, this is an imaginary room, and imaginary teams. But the splitting's real, alright?)

Both teams have to guess a 4-digit number.

Team A must guess all 4-digits at once. If they guess wrong, you tell them "wrong". And then it's Team B's turn.

Team B must guess one digit at a time. They guess the first digit. If they guess wrong, you tell them "wrong" and then it's Team A's turn again.

How many guesses might Team A need? It could be as many as 10,000.

Team B might have to make 40 guesses - 10 for each digit.

If we opened a book on this game, which team would you bet on?

Team B, obviously. They have odds of 250:1 of being the winner.

Okay. So let's speed things up a bit for Team A. For every guess you allow Team B, Team A gets 10 guesses.

So who would you bet on now?

Still Team B. They have 25:1 odds of being the winner, even though Team A delivers guesses at 10 times the velocity.

You can probably see where I'm going here.

In an iterative process like software development, over time what defines winners and losers is not how fast teams deliver features. It's how fast they learn about what works and what doesn't for their businesses.

Delivering less in each cycle actually helps them to learn faster. In software development, most of the value comes from acting on customer/user/market feedback.

Every feature we're asked to deliver is at best a guess. And we can cram as many guesses as we like into each cycle of delivery, but our productivity is not defined by this. It's defined by how readily we can act on the feedback we get with each delivery. The more frequent the feedback, and the longer we can sustain our ability to act on feedback, the sooner we will arrive at the real value in what we're creating.

In a market like Video-On-Demand, we can be sure of one thing. Whatever strategies work today, they will probably be irrelevant tomorrow. The challenge of products like YouTube, iPlayer and Canvas is in recognising that continuous, sustained evolution in years to come is what will define the market leaders, not fast delivery to gain market share in the short term.

Software development's a marathon. You cannot break a 26-mile marathon down into a sequence of 100m sprints. You run the inevitable risk of sacrificing the race just so you can have the fleeting honour of being in first place after the first few hundred metres.

Technical debt is a useful analogy, but I find lactic acid much more compelling. If you start a marathon at a sprint, lactic acid builds up faster in your muscles and you'll very soon find it impossible to go on.

If you "sprint" to deliver code, the crap builds up faster, too. I've seen so many software-intensive businesses rush at the start to take an early lead, only to end up being carried off on a stretcher a year or two later while their more disciplined competitors slowly but surely creep ahead and end up in front.

I'm pretty sure the bright young things who are tasked with consulting for the government on these issues, and the whole Digital Economy thingummyjig here in the UK, have completely overlooked this. I don't see it mentioned in any of their literature, and as a software development coach working in this space, I'm not aware of any software developers being consulted about it.

Software craftsmanship is one of the defining factors in the long-term success of digital businesses (as well as traditional businesses who rely on software, which is pretty much every major UK company these days).

I don't dare to imagine that those charged with shaping the UK's digital strategy will even begin to comprehend how important clean code is in the overall equation. But the logic and reality is inescapable. If code is hard to change, it cannot easily evolve. And if software cannot easily evolve, our digital economy could end up being carried off on a stretcher in the not-too-distant future with crippling muscle cramps and exhaustion.

We humble, voiceless and invisible code monkeys are actually a critical limiting factor on the fortunes of "Digital Britain", every bit as much as the people who built the ships and railways and bridges were for "Steam Britain".

I do not expect the government to acknowledge this. Nor Martha Lane Fox or Tim Berners-Lee. I do not expect building the UK's software development capability will ever be anything more than a footnote at best in the digital strategy (right now, it's not even that).

So I guess it's down to us. We can lead by example. Hopefully if enough of us show the way and commit ourselves to the goal of continuous delivery of clean, reliable code, and to being ready, willing and able to adapt our code based on feedback, the people who pay us will get the opportunities to learn and evolve their products and services fast enough to keep pace with the competition.

Chances are nobody's going to ask us to do it. And we probably won't get paid more if we do it. Likely as not, they won't even thank us.

But deep down, we care, and that's why we know it's the right thing to do.

Session Inspirations for SC2010

 

I've had emails from folk who are coming to Software Craftsmanship 2010, and would love to lead a session, but are a bit stuck for ideas.
It's easy, really, though. Do what I do. Take an existing kata (or "etude", as I prefer to call them 'cause I'm a musical, peace-loving kind of guy) and add a twist.

For example, how about running the Roman Numerals kata (yawn), but forbid people to use the mouse/touchpad (hoorah!)? Or FizzBuzz, but the rules are that you can't have more than one line of code in any method? Or how about a bit of deliberate anti-craftsmanship? How many code smells can you cram into 100 LOC? What's the most complex implementation of "Hello, world!" you can conjure up in 30 minutes? We can learn a lot about doing it better by trying to do it worse.

A boring old exercise can become an interesting challenge with a couple of extra rules. Like swimming lengths, but this time you gotta do it in your pyjamas.

Or how about working off a Bletchley Park theme. The logic of an Enigma machine fits into about 50 lines of code, which is just right for a 60-90 minute TDD workout. Just Google "enigma machine" + your favourite programming language and you'll be surprised how many examples there are. You could run a spy school and have pairs compete to send each other messages with their Enigma simulators.

Practice is not just about mastery through repetition. We need to stretch ourselves, and spicing up old katas is a great way to add variety and to make us work those codecrafting muscles.

Donate One Day's Pay To Bletchley Park

 

September 16th is Work 4 Bletchley day.

Nearly one hundred people, many of us software professionals, are showing our gratitude to the people and the place that hastened the end of WWII (by an estimated two years, saving countless millions of lives) and saw the invention of the first electronic programmable computer.

Personally, I owe the men and women who worked at Bletchley Park a great deal. My father was born in 1946, and had the war not ended in 1945 he may not have been born at all. Indeed, there's a significant chance you might be a descendant of one of the estimated 22 million people whose lives were saved. And I don't know about you, but I haven't done at all badly out of the whole computing thing, either.

For 6 long, hard years the people of Bletchley Park worked around the clock to gather vital intelligence that meant life or death to millions. We can say "thank you" by working for them for just one day.

To secure £4.5 million in lottery funding, which will transform Bletchley Park from a struggling and under-funded labour of love into the world-class heritage centre and hi-tech research and business park it deserves to be, they must raise £1.5 million themselves from other sources.

We can do our bit. One day's pay is 0.5% of your annual income and approximately 0.02% of the money a programmer can earn in their career. If enough of us donated a day's pay, it would make a real difference to their finances and push them closer to achieving their target.

I know times are hard, but computing is still a staggeringly wealthly profession. Some of the world's richest people have made their money off the back of work done by computing pioneers who worked at Bletchley Park, and sadly these IT magnates have chosen, for whatever reason, not to lend their support. It seems somewhat ungracious that an industry as successful as ours can be so indifferent to its own roots.

So it falls to us, the not-so-wealthy-but-still-pretty-comfortably-well-off, to do our bit. Together we can make sure Bletchley Park has a bright future that will inspire our children - and their children - to learn about the incredible achievements of the code-breakers at Station X, and maybe even download a copy of Eclipse or fire up their Office VBA editor and have a go at this thing we call "programming".

So please consider donating your pay for Sept 16th, and please tell other people about Work 4 Bletchley. If you can't afford a whole day's pay, we'll be grateful for any amount you can spare - half a day's pay, an hour's pay. Give what you can. It will make a difference.

Express Yourself In Code: Seeking Session Leaders for SC2010

 

Hello there!

As you may have heard, Software Craftsmanship 2010 has sold out. Which is great news for Bletchley Park and great news for software craftsmanship in the UK and Europe. I'm not aware of any conference in our line of work that has sold out as quickly.

Having a mansion full of enthusiastic craftsmen (and craftswomen) with their laptops, coding together, will be an exciting experience. The coding sessions at SC2009 went down very well, and it was great to see some well-established practices and theories coming under practical scrutiny.

Session submissions have been coming in, albeit slowly, and I think we already have enough great sessions to fill one track.

If you're stuck for session ideas, or a bit put-off by screencasting, I thought I'd post a few pointers which might spur you on.

1. Screencasts are easier than you think. The tools are out there, both free and commercial, and your screenacst doesn't need to be a polished video production. If it's a bit rough around the edges, a bit unrehearsed, don't worry. As long as people can get what you're trying to say, it's good enough.

2. Tools: I use Camtasia, which is very good indeed for screencasting. They have a free 30-day trial, which gives you plenty of time to record your SC2010 submission. Free screencasting tools include Jing and Camstudio.

3. Rehearse your screencast. Just run through it a couple of times to iron out any major kinks.

4. Cue cards. Bullet-point a rough high-level outline of the order of your screencast and key points to cover.

5. Keep a back up of any initial code. If you're going to run through it 2-3 times, and you're starting with some code already written, make a copy before you start.

6. Keep it simple. If it's a complicated screencast, it could be a very complicated session. Take a look at some of the submissions so far to get a feel for what would work well in a 30, 60 or 90-minute session.

7. Don't be afraid. We all worry too much about coding in front of an audience. First you'll disover is that you're really no worse than the rest of us at typing and using the shortcuts etc.And we're not expecting everyone who submits to be a coding rock star. Indeed, less of those would be dandy, thanks very much. If you've got a technique, a kata, a burning question, a challenge or just a bit of silly fun, we want to see it. Expressing yourself in code is the most meaningful way for a programmer to communicate, and at SC2010 we want to hear ideas from all quarters.

8. Video hosting in HD is now pretty commonplace. YouTube supports up to 1080p, Vimeo up to 720p. and for videos < 10 mins and 1 GB in size, it's completely free. If you're screencast is > 10 mins, just break it into smaller chunks.

Sharing is very much a cornerstone of craftsmanship, and free and cheap HD screencasting's giving us a way to share like we've never been able to before. If a picture's worth a thousand words, a 10-20 minute screencast can pretty much convey a whole book. It will be interesting to see what effect this has on the learning curve in software development as a whole, and especially within the craftsmanship community.

[Video] Rock S.O.L.I.D. - S is for Single Responsibility

 

Book your place on Rock S.O.L.I.D., Bletchley Park, Sept 16th. All proceeds got to charity.

OO Design Principles In Practice

 

From the Codemanship blog:

I'm running the first of the newly redesigned OO design principles workshops this weekend in London (and a -day version on Sept 16th at Bletchley Park - places still available and all proceeds to charity).

OO design principles run the risk of being a bit too abstract and theoretical, and the major challenge has been to reframe my original training to be as hands-on and practical as possible. Indeed, this may be where so many OO courses and books have faltered.

A particular challenge is to apply the principles on a day-to-day basis. How does S.O.L.I.D. translate into coding habits?

Well, I've had a stab.

Read More...

SC2010 Session Leaders

 

I just wanted to quickly clarify something that I'm sure most of you already know, but I've had a couple of emails asking, so I thought I'd better post something.

To lead a session at SC2010, you need to be registered. If you were planning to lead a session but didn't register before we sold out on Monday, I'm afraid you've missed the boat for this year's conference. I wish we could take more people, but the places are limited. There'll be another one next year, but please don't forget to register.

Rock S.O.L.I.D. OO Master Class In Aid Of Bletchley Park

 

Sept 16th is work4bletchley day, where a whole bunch of us who haven't done at all badly out of the whole computing thing are donating one day's pay to help Bletchley Park.

To raise even more cash, I've decided to make the best use of that day I can. So I'll be running an intensive and very hands-on master class in object oriented design principles for the very reasonable price of 249 GBP (the average one-day OO course costs 500+ GBP). Every penny of the profits will go to Bletchley Park. I'm not even claiming expenses.

So you can do double good on Sept 6th - get to grips with good OO design and help preserve the birthplace of modern computing to inspire future generations of software professionals.

The fun-packed day will include a tour of Bletchley Park.

You can find out more by visiting Codemanship's training page, and book through the Bletchley Park online shop using your credit or debit card.

It's all in two very good causes - clean code and Bletchley Park - so please tell your friend and colleagues.

Software Craftsmanship 2010 Is Full

 

Well, you could have knocked me down with a feather. Barely 3 weeks after we opened registration and SC2010 is now full to bursting.

Big thanks to everyone who registered. You've done a great service to craftsmanship and Bletchley Park.

And commiserations to anyone who didn't manage to get a place. But please don't be downhearted. If you follow the SC2010 submissions blog, you'll get to see screencasts of the practical elements planned for every session (including any sessions that don't make it), which is almost as good as being there. Well, maybe not. But it's a start.

Eden Development Sponsors Software Craftsmanship 2010

 

I'm delighted to announce our first officially confirmed Gold Sponsor for SC2010. Those brilliant chaps at Eden Development are supporting craftsmanship and Bletchley Park with their generosity. These folks take software craftsmanship very seriously, and if you're coming to SC2010 (which is sold out, by the way) then seek them out in the conference reception area or in their sponsored track and you'll find out about all the very cool work they've been doing.

If you'd like to sponsor 120 rabidly enthusiastic software craftsmen on October 7th, and help the birthplace of computing into the bargain, then drop me a line.