Software People Inspiring

QCon London Slides & Notes

 

If you can't make my session at QCon tomorrow, you can get the slides and brief notes here.

Of course, you had to be there, really...

Demonized

 

Another week and another of my rubbish guitar-oriented demos. This one's got synths on it. And thunder. Synths and thunder, that's how we do things in South London!



My apologies to music lovers everywhere.

Play My Latest Track & Make It Number One

 

Against the advice of my doctor and my accountant, I've recorded yet another guitar-based rock demo. Oh the humanity... To add insult to injury, I'm dedicating this number to the readers of my blog. It hardly seems fair, does it? I mean, what have they ever done to me to deserve such punishment?



I know. I'm utterly shameless. I want to climb the RiffWorld weekly chart and get one of those little gold cups on my profile, so please help by playing my rubbish song - even just for a few seconds. Every play counts. Because that's how it's done these days. Merit Schmerit! I just wanna be Number One!

If You Want Things Done Right, Manage Yourselves

 

Hello, there. Are you one of those people? You know the ones I'm talking about. They sit around in meetings all day. They have Blackberrys. They take 6 weeks to respond to an email, despite spending most of their time checking their inbox, and especially if it's from someobody unimportant, like a programmer.

That's right. I'm talking about managers. We need managers, right? Our project would go off the rails without a firm hand to guide it. I mean, how will the programmers know what code to write? How will the customer know what features to ask for? How will the testers know what scenarios to scrutinize? How will the software get deployed? How will new programmers get hired?

Underlying the need for managers on software teams is a set of assumptions that there are things that won't happen unless someone is there to manage them, and that there are important things only a manager can do.

Talk to customers? You need a manager for that. Schedule work? You need a manager for that. Hire a programmer? Yes, that's management business alright.

It's true that projects need accounting and budgeting and stuff like that. I have an accountant. He's called Geoff. He does my books and tells me off when I lose a receipt. Guess what, though? He's not the boss of me. He doesn't go out and speak to clients on my behalf. He doesn't win business for me. He doesn't decide what days I work. He doesn't have any say in when I take my holidays, or which graphic designer I should use for the Boffoonery programme (I did it myself in the end, by the way, because I'm cheap). I do all of this myself. He just balances the books at the end of the year and tells me how much tax Her Majesty's bloodsuckers will have to prise from my cold, dead hands.

I'm a programmer. No, seriously. And I can pick up a phone and speak to a recruitment consultant about sending us some CVs for a programmer role on my team. I can run a stand-up meeting and I can run a planning session with both hands tied behind my back. I can order stationary. I can put up whiteboards. I can tie my own shoelaces and wipe my own arse. Because I'm a grown-up. Well, maybe.

Having had one foot firmly in the UML and use cases camp for well over a decade I can certainly handle requirements, and can talk directly with the customer - who is also a human - and help them articulate what they need from the software without the need for a translator.

I understand business. I run one. I get invites to join the Institute of Directors and everything. And you say "oh, but that's rare among programmers". No. No it isn't. I've met a few programmers in my time, and despite a handful of very interesting characters who wouldn't function in any social situtaion - including working with other programmers - I'm confidently calling bullshit on that myth. Programmers understand business every bit as well as their managers. Possibly even better, since their managers haven't had to describe how their business works in bloody C++ or whatever. If you really want to test your understanding of something, try explaining it to a computer.

Projects need administators, just like my business does. I'm not a qualified accountant, and I need someone who really knows their stuff to make sure my books are tickety-boo and Mr Tax Bastard is fed the correct number of pounds of flesh. But I run my business. And hundreds of thousands of freelance programmers are in the same boat. They have to understand business, because they are one. And we spend our lives immersed in the customer's business to a level of detail the customer themselves probably doesn't go into.

I believe in self-managing teams of professional programmers. They can do the hiring and firing. They can work with the customer on requirements, testing and planning/tracking. They can order the stationary they need. And, very much an upside for them, they can decide things like how much refactoring is really needed, how much time can be invested in learning and practice each week, what documentation is really needed, and all manner of things that really are best left to the people who are actually doing the work.

And when they're too busy doing code and stuff (bearing in mind how much of their time would be freed up not having to persue pointless management agendas), they can send their Project Gimp to do it for them. Leadership can and often does come from within the team. A leader can be a programmer. And we can all be leaders at some point, when we're best placed to make certain decisions or provide a certain kind of direction.

And for those programmers among you who are thinking "but I don't want to do all this stuff"; maybe you don't, but if that's the case then stop complaining when your managers waste your time doing dumb shit (as they are wont to do). If you want a job doing properly...

Code Metrics Show Convincing Picture Of Impact Of Peer-based Craftsmanship Coaching

 

I'm sure they won't mind my sharing this with you. I've been putting together a presentation for managers in TV Platforms at the BBC, where I've been running a Peer Group Learning & Assessment program to help engineers hone their TDD and refactoring chops.

It's been bubbling away in the background for about a year with 8 of their engineers, and is now rolling out to other peer groups, so by the end of this summer pretty much everybody writing code in TV Platforms will have been through the basic TDD practice regimen and hopefully successfully passed a gruelling practice-based peer assessment to demonstrate that they're truly in the habit of doing things like running the test to see it fail and not refactoring on a red light etc.

Anyhoo, for the presentation, Kerry Jones - TV Platform's key technical design authority and a thoroughly good craftsman in his own right - threw together some code metrics to give us a picture of the "before" and "after".

It's looking good, I have to say. Remember this is data culled from projects in which only 8 of the engineers have been through a TDD PGLA exercise - that's about a quarter of all the TVP engineers.

Test coverage is up by about 40%. Method length and complexity has dropped by roughly 10-15%. Duplicate code has dropped by more than 50%.

Now, their stats were by no means bad to start with (the BBC have a much higher-than-average quality of developer, I'm finding), and it's usually much more dramatic when teams are starting from rock bottom (low-hanging fruit and all that), so these improvements are all the more striking. This is by far and away the most encouraging result I've had from a coaching program, and I'm quietly confident that as we delve into the murky world of refactoring and legacy code, and incorporate data on dependencies on OO goodness/badness into the picture, we'll see yet more improvements.

Whether project managers will give two hoots remains to be seen, but when we make the link between factors like test assurance, complexity and duplication and productivity and cost of change (already well-established through SEI, IBM and other studies), it's a picture that's hard to dismiss.

If you want to know what PGLA is all about, I'll be giving the lowdown at QCon on March 10th, and Kerry and I are booked in to talk about PGLA and software craftsmanship at the BBC at XP2010 this summer.

When Does "Delivered" Not Mean Delivered?

 

On occasion, I take a calculated risk and buy something off eBay. Ninety nine times out of a hundred, I suppose, the sellers are on the level and ship my item as soon as my payment's cleared. Right now, I'm awaiting delivery of an item from the US, which I purchased about two weeks ago.

The seller shipped it by standard international parcel post and I've been able to track its progress via the USPS web site. Which is how I know it left the US on Feb 11th and arrived in the UK on Feb 17th. So far, so good.

But this is where things all go a bit Twilight Zone-ish. According to USPS tracking (which must now be gettings its data from Royal Mail tracking at our end), they "attempted" to deliver it at 11.20pm last night.

Uhuh? Are we doing parcel deliveries after the pubs shut now? I believe not. "Attempted" delivery I understand to mean that they stuck it in a delivery van and the van came to my house and the driver knocked on my door and there was no answer. Or they couldn't find the house. Or something like that. Basically, they tried to deliver it, but were unable to for some reason.

I was most definitely at home at 11.20pm last night, and wide awake, and sober, and would most definitely have noticed if someone had knocked on my door at that unsociable hour.

This is not the first time that an overdue parcel delivery has been tracked as "delivered" or "attempted delivery" via our esteemed postal service - the oldest (and now, it seems, the creakiest) in the world. I orderd a box of expensive cigars a few months back and it disappeared into their system for several days, while all the time showing as "delivered" on their tracking web site.

It eventually turned up, of course. And I pointedly asked the nice lady who delivered it why it was down on their system as "delivered" when it quite obviously hadn't been up until then. And she admitted, with little hint of embarassment, that this happens all the time and is done to keep their performance statistics looking good.

This is a growing malaise in British life. Targets and measures are routinely gamed by put-upon workers who frankly are given no reason to give a shit. Actually delivering the parcel is less important than being seen to have delivered it on paper. The management perception of performance and reliability weighs most heavily on the worker's shoulders - far more so than the customer's perception of the quality of service they're getting. So much so, in fact, that when I've dared to complain to sloppy service providers, they've called me a liar because their database systems clearly show a rosier picture than the one I, a mere customer, have painted.

This is all very well and good, having a Saturday morning moan and all. But there's a salient point at the end of all this. I've seen countless teams - Agile and otherwise - game their delivery data in much the same way. When you give the people doing the delivery the power to decide if something has been "delivered" and when their management relies on this highly subjective picture to assess the reliability of releases (by which I mean, when we say it's been delivered, has it really been delivered), we get a similarly disparity between the customer's perception and our own.

Of course, the postal delivery system is supposed to have checks and balances to make it more objective. How could something be "delivered" without a signature? Well, obviously it can, somehow. Perhaps the signature isn't really required. Or maybe any signature will do.

The solution is to place full responsibility for deciding if something has been successfully delivered with the end customer. And to establish very clear criteria as to what constitutes successful delivery. As it turns out, requiring a signature is by no means fullproof. What would probably work better is if customers were given a secret number or password to enter into the courier's little handheld computer thingy - or a barcode to scan - or something that can only be obtained by making contact with the person for whom the letter or parcel is intended.

In software projects, we need something that is a clear and unequivocal indicator that "the ball is in the hole". Not near the hole. In the hole. And this must be something that only the person who raised that specific requirement can control. Developers must not be allowed to make changes to the criteria. Only the customer should have that power. And these criteria must be beyond any doubt. They cannot be vague or handwavy, because that makes them game-able.

Practitioners of acceptance test-driven development will have some idea of what I'm getting at here. But I've watched teams doctor the test scripts without informing their customers, just to make a failing test pass and to meet a deadline, resolving to fix the real problems after they have "successfully delivered".

This cannot be allowed. ATDD works best when only customers have this power. Test scripts should be locked down in the customer's version control system, and nobody who touches the code should have the authority to check in new versions of the acceptance tests. If we want to move the goalposts, we must be forced to go to the customer and ask their permission.

Now, where's my bloody parcel?!

SC2010 Audition Video - Refactoring Golf

 

Here's another really great audition for a session at Software Craftsmanship 2010 from UK Agile veterans Dave Cleal, Ivan Moore and Mike Hill called Refactoring Golf.

It's a neat game you can play with refactoring exercises where you are given a "before" and an "after" in code, and you must refactor to get from A to B (the proper, disciplined way, and using your IDE's automated refactorings as much as possible). Just as in golf, various actions cost you points, and the aim of the game is to complete the refactoring racking up as few points as possible.

I'm excited about this audition: firstly because you can't really go wrong with Dave, Ivan and Mike, and secondly because it's using a golf analogy, which is a sure sign of quality in my book.

Of course, now that the cat's out of the bag on this game, you have 6+ months to practice your Refactoring Golf swings (and your putting, let's not forget), so this session could be a really fun experience on the day. Not that it will be up to me, of course. You will decide which auditions make it into the conference, so take a look at the video, have a go yourself, and let us know what you think.

Software Craftsmanship 2010 Will Still Be in 2010 - But A Bit Later Than Originally Planned

 

After careful reflection, I've decided to push the Software Craftsmanship 2010 conference back into late summer or early autumn.

There are three good reasons for doing this, which I hope you will understand:

1. It looks as though people will want/need more time to dream up and hone their session proposals, so an extra 2-3 months will hopefully transalte into a better conference

2. With more time, I may be able to raise more sponsorship. Possibly even enough to completely fund the conference.

3. There are other software development conferences happening at Bletchley Park in early July that we would possibly clash with

All of this means that a late September or early October SC2010 is likely. My ambition is that it will be a unique event, quite unlike any conference you've ever been to, and that its organisation will be more open and transparent, and more democratic and meritocratic, too. If I can raise enough cash, it might also be free. But I can't make any promises.

The time to start working on your session audition is NOW. 6 months goes faster than you think, and the sooner you present the world (and his eponymous dog) with you demos, the sooner they can help you iron out the wrinkles and evolve it into exactly the kind of conference session that will turn heads.

Email links to your audition demos to me here and I'll regularly post them on this blog.

Wheel-driven Reinvention

 

One aspect of software development which is at once both amusing and troubling is the ability of us young whippersnappers to completely ignore what's gone before and reinvent established wisdom in our own image - often stealing the credit.

Take testing as an example. What do we know about testing software today that we didn't know, say, thirty years ago? Sure, we have new tools and testing has to fit within new approaches to the process of writing software as a whole, but fundamentally what have we discovered in the last decade or so?

Testing behaviour still works, by necessity, much as it has always worked by necessity. We must put the system under test in some desired initial state, then we must provide some stimulus to the system to trigger the behaviour we wish to test, then we must make observations about the final state of the system or about any behaviours that should have been invoked (e.g., a remote procedure call or a database request) in response to the combination of our stimulus and the initial conditions. And this process must be repeatable and predictable, like any good scientific test.

Though the culture of testing software may have evolved, much of it for the better, and the technology may have improved (though that is questionable), and though there are undoubtedly more people testing their systems today, when it comes to the business of writing and executing tests, there's really nothing new under the sun.

The same is true of many aspects of contemporary software development. Like it or nay, iterative and incremental development is older than C. We just weren't doing it back then, in the main.

Indeed, pick any "new" aspect of development and trace it back to its roots, and we discover that most novelties are actually much older than many of us thought. Objects are an invention from the sixties. Use cases hail from the seventies. Responsibility-driven design was being practiced before Frankie told us to Relax. UML existed in a fragmentary form before the Berlin Wall came down. People were writing code to satisfy tests back when those tests were stored on magnetic tape. Indeed, some of the descriptions of programming that was done for the very first computers rings bells with those of us who practice that black art today.

Younger developers like me, though, seem to readily believe that our time around is the first time around and feel no compunction to educate ourselves about the achievements of "old-timers", preferring instead to invent things anew - with sexier names and shinier tools, admittedly.

Our desire to reinvent goes as far as redefining words that already have a well-established definition. "Agile" no longer means "nimble" , "quick" or "spry". Today it apparantly means "communication, feedback, simplicity and courage". Or "iterative and incremental". Or "evolutionary". Or "Scrum-Certified". I caught someone the other day proferring their definition of "testable", which apparantly now requires us to go through "public interfaces". This is bad news for many scientists, who must now rewrite their peer-reviewed papers to incorporate the appropriate programming language with which to express the "testability" of their theories.

If software development was physics, we might expect newcomers to work through and understand the current body of knowledge before they start adding to it. That way, at the very least, we could avoid a great deal of duplication of effort. We may also avoid the tendency of our industry to throw "old-timers" on the scrapheap just because, even though they are probably just as current in their practical ability to deliver working software, they're not "down with the kids" on all the latest street slang for concepts that have been kicking around the block for decades.

The thinking of our elders and betters is far from irrelevent and outmoded. We can still learn a thing or two from the likes of Jacobson, Knuth and Hoare, should we choose to reject fashion in favour of substance in the approach we take to our work.

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!