Keynote: Innovation at Google, Patrick Copeland
The day started with a whistle-stop tour of innovation by Patrick Copeland. the “at Google” bit of the title was a bit of a misnomer as it was classic “innovation funnel” textbook stuff (though he didn’t use the term.) This isn’t a criticism though as Patrick did a superb job of covering the principles of innovation – from the notion that ideas by themselves are worthless through prototyping early to weed out the crap to failing fast to avoid throwing good money after bad – in just an hour, which is no easy task. The day started well and was only going to get better.
Craftmanship and Software Engineering, Glenn Vanderburg
This talk started with the suggestion that software engineering as an idea had failed and that software craftsmanship had replaced it. To my mind, this assertion is complete crap. I saw it as more a case of software craftsmanship was – like software architecture – just another silly trendy buzzword. I’d assumed that buzzword had came about because “engineer” wasn’t as great a term to align software with as it was in the 60’s. However I try to adopt an approach of seeking out contrary views to my own to test my own beliefs. Sometimes this reinforces my view that I was right all along. Sometimes I change my mind. Then very occasionally someone likes Glenn wanders by and renders the whole debate pointless by presenting a compelling third position.
Many developers have a set of preconceived ideas about engineering, which have been applied to software and failed spectacularly as a result. Engineering is a science; engineers generate documents that enable others to build the system; engineers use maths to prove their designs; engineering is a well proscribed discipline which involves turning the crank to output predictable results etc. In the 60s, some folk tried to map software onto these ideas, and ended up with the horrible mess of the document-code-test waterfall method that developers then suffered for the next three decades.
These ideas are pretty ridiculous though. For example, engineers use mathematical models as they are cheaper than over-engineering or testing the real system to destruction. Engineering is as much craft and art as it is science. However it was the use of documents by engineers and how this was mis-applied to software was the real inspiration moment of the talk.
In the past when we mapped engineering onto software, we took the engineer -> document -> builder -> product work flow and came up with analyst (nowadays architect) -> specification document -> coder -> compilable code. This is though a farcical mapping. The point of software engineering is not to create source code, it is to create a runnable program. The real mapping is developer -> source code -> compiler -> program. In other words the compiler uses the engineer’s instructions (the source code) to create the product.
In civil or mechanical engineering, the most expensive stage of the engineering process is building the product. So the more they can use maths to model the end product, the cheaper it is for them. For software engineering though, building the product is the cheapest part as compilers take seconds, or at most minutes, to create the product from scratch. So what need do we have for mathematical models that are always imprecise approximations of the product? For us, the cost is all in the engineer’s time in creating, or later maintaining, the documents (the code.)
The location of the cost is where software craftsmanship comes into it. The code may be compiled by a compiler to create the product, but compilers can handle all sorts of badly written, humanly-incomprehensible garbage code just fine. It is at least as important to think of the quality of the code when writing it as whether or not it compiles to a functional program. Your code should be a thing of beauty: easy to understand and maintain, well written, well documented and refactored until it bleeds. If you do that, you can legitimately call yourself a software craftsman.
This talk was sheer genius to my mind and, inspired by Liz’s “focus on the positives” talk yesterday, I made sure I thanked Patrick in person at the end of the talk.
When the pressure is really on, Katherine Kirk
Katherine works for a large British business that, like many large businesses, puts bureaucracy before common sense at every level of its business in every way it can. Managing software projects in such an environment can be thankless, soul-destroying task. Katherine’s talk explained how she used the ideas of Lean and Kanban to help her manage those projects.
Whilst Kanban techniques undoubtedly helped the situation, I was left wondering whether they were the true reason why the projects succeeded, or whether it was her management skills that truly saved the day. I suspect it was a combination of the two. Either way, it left me inspired to try out Kanban as a tool to help the company I work for manage those development tasks that are not well-suited to Scrum, our current agile tool of choice.
Can the Kanban Method avoid becoming another Management Fad, Benjamin Mitchell
This was an odd talk. Benjamin was a very good speaker: good style, amusing and he kept me interested. However by the end of the talk I was left wondering just what he point was and how it related to Kanban. I expressed this view on Twitter and was reassured to find that Benjamin too had struggled with the talk. So once the conference is out the way, I’ve agreed to email Benjamin to discuss it further with him.
Complexity vs. Lean: The Big Showdown, Jurgen Appelo
QCon is a conference structured around topic tracks, and it appears that one of the objectives given to the person charged with setting up a track is to have one session that challenges the ideas of that topic. This talk by Jurgen was one such “Devil’s Advocate” talk that challenged Lean and Kanban. Jurgen did it very well indeed.
One can view Kanban as a model of a production process. Like all models it is an over-simplification of reality. Life is full of complex systems, in other words systems that exhibit one or more behaviours that are neither present on, nor predicted by, the parts of that system. When we model those systems, we lose that emergent behaviour and we risk forgetting that that emergent behaviour is there. Being a relatively new idea in software development, advocates of Lean and Kanban tend to get excited and passionate about it and risk presenting it as a solution to all the industries woes. This talk was a reminder that it is just a model – a simplification – of a way of working and that we must remember this when using it.
To illustrate what he meant, Jurgen examined the principles of Lean and Agile and questioned each in turn. For example, one of the principles of Lean is “Eliminate waste”. Jurgen suggested that this was an over-simplification. If the waste isn’t costing you anything or taking up valuable space, eliminating that waste will actually cost you more than just allowing it to be. To take another example, “Delivery fast” is a principle that fits well with the agile, test-orientated, process. However sometimes, anticipating future needs and spending a small amount of time now to make it easier to incorporate new ideas in the future can save time and money in the future.
The talk had a similar ring of pragmatism to Dan North’s “Minutes to Months” talk yesterday for me. Simple principles are great for guiding beginners, but never view them as unquestionable “best practice”. When the model conflicts with reality, pragmatically ignoring the model will always triumph over slavishly following it.
The Beginner’s Mind, Patrick Kua
The last talk of the day was a well-structured and presented examination of the “expert trap” that we we all have either fallen into in the past or will do so in the future. As we get more knowledgeable on a topic, we all tend to get less open-minded about it. We know the answers after all, so how can we be wrong, or so the thought goes. As Patrick superbly put it: “In the beginner’s mind, there are many possibilities; in the expert’s mind, there are few.”
Software development though is a fast-changing business. If one rests on ones laurels, one quickly becomes out of date. Similarly, if one closes one’s mind to new ideas and to the possibility that yesterday’s good truisms may not hold today, one risks becoming more asinine than expert. Patrick’s advice on avoiding this trap was all good common sense stuff: remain curious, always question your assumptions and embrace other people’s opinions.
And so ended another great day at QCon. Can day three hope to compete with this? Stay tuned…