Gems from QCon London 2010, Part 1

Here’s my list of gems from the recently held QCon London conference on software development. These are only my impressions so you have to take them for what they are: Quickly scribbled notes and hastily drawn impressions. This is part I. >>Part II

Robert C. Martin (“Uncle Bob”): Bad Code, Craftsmanship, Engineering, and Certification

Bob Martin jamming on stage

To watch an Uncle Bob speech from the 2nd row of a big auditorium is a bit like being run over by a train. 700+ people there and Bob would probably not need the microphone. He is certainly a convincing speaker.

The message has been repeated a few times now but here are some things I think are worth mentioning:

• Remember the Boy scout rule: Always leave things a little better than it was when you arrived. If all developers did this we would gradually make things better and make our systems liveable again.
• Rule: Extract ’til you drop! Keep extracting until all functions only do one thing. This puts a name to each concept and each concept in its place.
• Rule: Never pass booleans to a function. It is obvious that it does two things; one if its false, another if its true.
• Rule of thumb: Name lengths should be inversely proportional to its scope. Public methods should be short, since they will be used a lot. Private methods deep down in a class should have long and describing names.

Remember, one certain attribute of a craftsman is that they never write bad code. Even under stress. If you have trouble remembering, order a green wrist band from the Clean Code Project. The only thing they ask is that you make a charity contribution.

Dan North: Sharpening the Tools

Dan is speaker that is a joy to listen to; with a great sense of humour. Sometimes I feel that he has so much pure, British charm he doesn’t actually need much in the way of content.

Dan’s main message in this talk was that we as developers, from beginner to master, must never cease improving, i.e. sharpening our tools. Apparently, switching jobs was a humbling experience. Dan used “tools” in a very general meaning and could be anything from, for example, the technical, methodogical, personal, team or leadership domain.

Another tip from Dan was to use the “Six Thinking Hats” technique to get a group to reach consensus decisions, calling it “absolutely brilliant”. I picked up a copy of Edward de Bono’s book about it at the Science Museum in London.

John Hughes: The Joy of Testing

Despite his english-sounding name, John is a professor at Chalmers University of Technology, Sweden and one of the Haskell founders. He is also a great presenter; sharp, joyous, and enthusiastic. He described a way of testing systems called Property-Based Testing (PBT) with a tool called QuickCheck. (There is a commercial version for Erlang called Quviq.)

As I understood it, PBT means that instead of writing test cases you describe properties of your system. After that, a tool like QuickCheck can take it over and generate massive amounts of random tests. If it finds an error it tries to reduce the failing test case to the minimal case that also gives an error. This is used to improve the feedback to the developer.

John also demonstrated QuickSpec, which was a tool used for deducing and generating properties from examples.

I thought this to be an interesting approach. I am certain that it would find a lot of uncovered edge cases in my code. The problem for me is that it is so much targeted around testing, not around design and documentation, which, for me, are the main advantages of using TDD. How would describing properties help me in my design?

Corey Haines: Software Craftsmanship, Beyond The Hype

Corey held an inspiring talk on the software craftsmanship movement. I really liked his rundown of practical initiatives and activities that has happened under that umbrella; things that would never have occurred otherwise, for example, Kata video casts or Craftsman swaps between companies.

Corey said another interesting thing: Think about where you would really like to be, competence-wise and professionally, under ideal circumstances. This is your current goal of excellence. Then, think of how you develop software under stress. That’s when you revert to the practices you really master, not the once you are trying to adopt. Now, subtract the last from the first – that’s the amount you currently suck!

Track: Functional programming

There was a whole track Wednesday, hosted excellently by my Swedish countryman Ola Bini, on functional programming. Ola managed to create a very relaxed and friendly atmosphere in the room. Amanda Laucher was to go last in the track, presenting an explanation on monads. Unfortunately, she couldn’t make it and the replacement had very little time to prepare. Result? We still don’t understand monads completely. On the other hand, we are in good company.

Dan Ingalls: Forty Years of Fun with Computers

For the conference party keynote, QCon had selected Dan Ingalls. Dan is a legendary programmer, who has lead five major Smalltalk releases, among other things. He is also portraited in the book Coders at Work. Dan seemed to be a very friendly guy with a youthful enthusiasm for physics, graphics, and symbols.

Dan Ingalls showing off early Fortran skills

Dan showed us, and executed, his very first programs, written in Fortran, to spontanous applause. He described and illustrad the path he had chosen for his career, working with luminaries like Alan Kay at Xerox PARC. He describe the development of Smalltalk, on to Squeak (a Smalltalk implementation written in itself!), and today’s work on the Lively Kernel. This last thing is something so curiously wonderful as an interactive programming environment inside a standard web browser.

What struck me during Dan’s talk was that he always seemed to go where he thought he would have the most fun. That is a quite uncommon attitude in the often very serious world of software today. But it is not unreasonable to think that this attitude is actually a recipe for success. If you love your work, you are probably going to do an excellent job at it.