Software People Inspiring

Coding 'Til You Drop Gets The Thumbs-Down

 

I'm horrifically busy at the moment, which makes a change. But I just couldn't let this one go.

I tweeted this morning my career ambition. I would like to remain a programmer for the rest of my career. And I would like that to be seen as a good thing, and not a failure on my part to progress into management.

Programming is the most skilled job in IT. And programmers are the most skilled people. I would like to get better at it, and end my career on a programming high.

Because:

a. I enjoy it, and

b. Programming is kind of useful on software projects. The world needs working code.

Indeed, the world's appetite for working code grows ever more voracious. In the 30+ years since the first microcontroller was put in a car engine, we now have an average of 100 million lines of code in your luxury family saloon. I'm surrounded by devices that host millions of lines of code. My life, and probably yours, functions on working code every day. This is the information age, after all.

So if I enjoy programming, and the world needs programs that are useful, usable, reliable, maintainable, secure etc etc, then surely we have a marriage made in heaven.

And if I want to go on coding and not climb the career ladder into ever-more-lofty management positions, who could begrudge me that?

Well, someone could, it seems.

Bob Marshall (@flowchainsensei) retweeted it with a "-1" - basically, a thumbs down. He then tweeted:

"A focus on coding is self-indulgent and antithetical to the #lean ideas of value and flow, as well as to the #agile manifesto and principles"

Wow. I don't think Agile veterans like Uncle Bob Martin, Kent Beck, Ron Jeffries, Ward Cunningham, Steve Freeman, Nat Pryce, Ivan Moore, Joshua Kerievsky, Martin Fowler (and some bloke called Jason Gorman) got that memo. Somebody better tell them: if you want to be Agile, you need to stop coding beyond a certain age.

Now you'll have to pardon my French, but I couldn't give a flying fuck if I'm being "Lean", or frankly if I'm being "Agile", for that matter. I create working software. It is the software the customer asks for. Demonstrably so, as evidence by their acceptance tests - which are also expressed as code, because they need to be executable. So I have to deliver those, as well.

Now maybe in 2035 we'll all be creating software using pure thought channeled through a selection of genetically-modified winter vegetables, but that process will still be called "programming" and I want to be still doing it, and - if I pray to the coding pixies hard enough - maybe I'll be doing it better.

It's all very well saying "a focus on coding is self-indulgent", but no matter how unselfishly you manage your orchestra, you'll still need musicians who can "self-indulgently" make pleasing noises come out of their instruments using the enormous battery of skills they've built up over many years of dedicated practice. And nobody points at the pianist, or the lead violin or lead soprano and says "shouldn't you be a conductor by now?"

Nor do they accuse musicians of being "self-indulgent" in their ambition to become better musicians and not to persue a glittering management career at some record label or in the Arts Council.

If you love to code, and you're good at it, and if the world needs more and more working software, software of increasing sophistication and complexity, software that we come ever more to rely on in our daily lives, isn't it more selfish and self-indulgent to walk away from that calling?

Some people really need to go away and sit in a darkened room (or atop a distant mountain) and consider the realism of managing working software into existence. When the day comes when someone can demonstrate the creation of valuable software without programming (including "programming in pictures", before you MDA fans get too excited), then I'll hang up my IDE.

Rock S.O.L.I.D. Sept 16th

 

Talking of OO design, we still have a handful of places left on the OO design master class being run at (and in aid of) Bletchley Park on Sept 16th.

It's in a very good cause, and it's a packed and hands-on course that will provide a practical kick-start for OO newbies and stretch experienced developers.

A Job For Programmers

 

Managing programmers is a job for programmers.


Hiring programmers is a job for programmers.


Educating programmers is a job for programmers.


Maybe you're a programmer, and you'd prefer to avoid these jobs. But the reality is that nobody else is qualified to do them.

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.

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.