thekua.com@work

Keynote: Ralph Johnson on Living and working with aging software
The final keynote of the conference kicked off the second day of QCon and presented to us by Ralph Johnson of the Gang of Four fame and whose students contributed to Fowler’s timeless Refactoring book.

Ralph was asking about the number of people who work on systems they created (versus systems that other created) and then argued about the meaning of maintenance programmer arguing for software evolutionists instead. Whilst I agree that no one likes to be labelled a maintenance programmer, changing the name doesn’t really matter.

I like the different perspectives that Ralph brought. He talked about Software Capital as about truly understanding how the software works. Code is one example of this, but actually there are many other things that go into understanding how the software works. He argues that the right sort of documentation (and other artefacts) that helps understand how the software works is another part of Software Capital. As a result, you also need the people around the software to help keep the story alive.

My observations of various organisations also backs up some of the things that he says such as, the larger a system gets, the more likely you need some form of documentation and social structure around the software.

I think a lot of people didn’t like Ralph’s keynote because he talked about refactoring as if it was a new idea and, unfortunately this audience is one that has been exposed to these ideas for a long time.

Track: Beyond Tools and Technologies
I spent the rest of my time on the track that I was speaking at later that day. The first talk of the day was Martin Fowler whose talk, “What are we programming for?” brought the tiny room to a stand still. The room was so full (although it was a small room) that they had to turn people away.

Martin used the talk to highlight the importance of going beyond acting like hired guns and actually thinking about how to use the skills for something good. He asked people to consider the essence of the firms that they work for and whether or not they are benefiting humanity.

Rebecca Parsons, ThoughtWorks’ CTO then talked about the importance of team diversity in her talk, “How to avoid ‘We never even thought of that’!” She talked about the role that diversity played in creating innovations in science and how too much of the “sameness” creates problems with creating too many assumptions. I like the idea of a balancing tradeoffs of not enough diversity leading to problems in teams and too much diversity to the point that the team don’t share the same vocabulary.

After the lunch break, I ran my session, “Building the next generation of Technical Leaders“. I was very happy with the turnout and had some great feedback from the participants. It’s an issues I think is sorely neglected in our industry and has a huge impact on the team effectiveness.

The next session was run by our Director of Social Engagement (Jeff Wishnie) and Merrick Schaefer of Unicef discussing the importance that technology has on developing countries and the significant impact it can have on the lives. They talked about the Rapid FTR project that is being developed to help capture information about children who’ve been separated from their parents with hope of quickly reconnecting them, and at worst, giving them legal status by registering them with an agency such as Unicef.

The final session of the day rounded out with Mick Blowfield with a presentation titled, “IT in a Low Carbon Future“.

Whilst there were many other potentially interesting sessions, I was really happy to hear about the issues that go beyond just Tools and Technology.

Comments(0)

I’ve never been to a QCon before and being run by the same organisers of JAOO and the folks behind the ever popular InfoQ, I was looking forward to being both an attendant and presenter. Lasting three conference days and two tutorial days, this conference focuses mainly on being talked at – quite a different experience to the Agile 20xx and the XP 20xx conferences I normally run workshops/talks at. Being focused on the cutting edge and practical technologies side, I can really understand this because it’s hard to target people with the right level of experience.

Talking to most of the attendees, it also attracts a noticeably different side with the majority of people already in architect or senior developer roles with a relatively smaller proportion of people in other ancillary roles such as PMs, testers or BAs.

Feedback that works
I like the feedback note for the conference, asking people tweet, email or talk to people at the conference. I think some of the feedback mechanisms even worked as we saw a lack of caffeine/water during the breaks on the first day change for the other remaining days.

The Keynote
The first day’s keynote started with the evangelical Uncle Bob Martin. He’s a great speaker and channels a lot of opinion towards the crowd wandering back and forth on stage. I saw a version of this at the Agile 2009 conference. I’m glad he adjusted it somewhat more appropriately for this conference. He talked about some good principles that should be followed after a few bumpy technical glitches. He is all about the drama (which I guess is part and parcel of a keynote) such as showing us a video that scrolled through a single java class for something like two to three minutes backed up by a song from the movie from 2001 (thanks Ola!) that almost sounded like the flight of the bumblebee. The point of this showmanship was to demonstrate how we can sense bad code visually without even looking at the specifics. He went through a number of his mantras such as “The Boy Scout” rule, leaving things better than how you found them, or that functions should be no more than four or five lines long.

Whilst I don’t think I learned anything new, Uncle Bob Martin was entertaining and had good things to say, despite how preacher-like he comes across.

Track: Architecture’s You’ve Always Wondered About – Session: BWin – P5 a future proof poker platform
The rest of the day was split into six different tracks. I went to the first of these and was truly disappointed. The two presenters came from BWin, apparently one of the largest poker and gaming sites in Europe. They spent half an hour talking about their problems of performance (many of the -iliites) and where the history of their application came from. They even had to include a three minute video from their marketing folks. They finally flashed up a screenshot of their architecture diagram which I think everyone had come to hear about it. Unfortunately they moved onto the next screen very quickly and said that they couldn’t actually talk about their architecture. How disappointing! Indeed this might have been an “Architecture You’ve Always Wondered About”, and after this session was one to still, indeed, wonder about it.

They proceeded to pick a single example about two processes that concurrently wrote and read from the same database table and their architectural change simply transitioning it to a disk persistent queue and the reporting service reading from that queue and writing to its own database. Neither very profound, or a very interesting tidbit that failed to give the audience any more insight into any interesting part of how they architected their system.

I found it interesting they spent a long time (something like 250 man years) rewriting this version of their architecture so I asked the question about how they went about moving from their old to their new platform at which they pretty much described a big bang approach – neither iterative or incremental. Pretty disappointing.

My lesson learned from this: Regardless of how pretty your slides are, make sure your abstract matches what you’re going to actually talk about.

Track: Dev and Ops: A Single Team – Session: Devs and Ops Cooperation when the Worst Happens
My next session was much more fulfilling with Michale Nygard (author of Release It) describing some of the stories that were the basis for the book but wouldn’t have been publishable. Michael is really down to earth and happy to chat about many of the details behind the book. It’s really obvious that he is also a very pragmatic person, understanding that models are just that and recommending people look into the details because there is often something much more complex underneath.

Many of the things that Michael talked about also resonated very strongly with ideas that I’ve seen on applications. Many of them included focusing on ensuring documentation artefacts should be tested by those who will consume them. As he put it, “UML is virtually useless to the deployment and operations team”. Other gems included, “From a high enough view, everything starts to look the same”

His stories also reinforced the importance of having a ubiquitous language will all members of the company in the shared domain. One of his most successful rescue missions dealing with a production problem only worked because the architect (on the dev side) and Michael (on the ops side) understood enough to really communicate the real problems. Michael also kept (understandably) hammering home the point of lack of information on both sides really hurts the problem solving process.

A lot of Michael’s stories also described their successes working around the existing (organisational) systems in order to deal with the problems at hand. To me, this was just another great example of organisations that structure themselves for efficiency over effectiveness.

I like the way that Michael finished off his talk as well, focusing on the fact that you’re not just trying to build software, that you need to care about the organisation (and I would also argue, the systems and procedures in that organisation) that support the software. Design them for effectiveness, not efficiency.

Architectures you’ve always wondered about: Facebook
The next session I attended was by Aditya Agarwal (one of the engineering directors of Facebook). He shared some great insights and lessons learned into what things Facebook did that got them to where they were. Admittedly they had some strange choices like writing something that converted PHP into compiled C++ and using MySQL is a very “reliable bitstore”.

They have a lot of great things to say, like being very proud of the low number of engineers ratio to actual users. Like Alistair, I’m puzzled why they’re secretive of the exact number of their employees.

Aditya has some good things to say and although he means well, I don’t support everything that he says. it’s obvious a lot of what he says is based on a start up culture. Things like, “don’t worry about it until it becomes a problem” encourages the recklessness we see in many software companies. Same thing about the choice of programming language such as “every programming language will have problems at our scale”.

On the plus side, I was pleased to hear them encouraging the innovative engineering culture that I don’t see in many organisations.

Track: Non relational DBs and Web Oriented Data – Session: Social networks and the richness of data: getting it done with
After going through my notes the most interesting tidbit was about using a partitioning mechanism to deal with data updates based on the number of connections. There was plenty of buzzwords (both internal and external) that I think I had a hard time fitting it all together. Some things I’m going to look at include:

• Bit versus bloom filters – Not familiar with this term or how to use it.
• Tools – RESTeasy (I now see it’s a JBoss project). Redis and Voldemort – something they used heavily all over the place.

That’s about all I got out of this session though I’m not sure if it was about the lack of familiarity with the tools, or the excessive use of acronyms and unfamiliar terms or just plain tiredness.

Track: Functional Programming – Session: Demystifying Monads
Josh Graham did a great job stepping into fill in for his ill wife talking through some of the different ideas behind monads. I haven’t done functional programming since university and I’ll be the first to admit Monad’s are still a mystery to me but I came away with some key learnings.

Firstly, to understand monads properly, you really just have to see several examples in action. There’s a high barrier to entry because it means:

1. Learning a new language
2. Learning a new development environment
3. Playing with plenty of examples

When I find some time, I’ll do those. In the meantime, I understand a bit more about the properties of a monad, and that they can be a powerful abstraction for functional languages.

Final keynote – Dan Ingalls: Forty Years of Fun with Computers
For being so late in the day, this was a very entertaining keynote. Just like any modern day small talk person, this entire demonstration took place in the Squeak development environment. Dan demonstrated some interesting and interactive elements.

I had a few key takeaways including:

• We’re really bad at learning the lessons from the past. Partially because we don’t have enough storytellers and that our generation doesn’t listen very well.
• I’m going to read this article at some point.

Comments(2)

When you introduce agile methods to very traditional organisations there’s a side effect most people underestimate. This is, I believe, where the first line in the manifesto is most appropriate:

Individuals and interactions over processes and tools

Traditional organisations are geared for efficiency – keeping individuals busy to the point where you lose overall effectiveness if you ever need to synchronise between parts (which you inevitably do for software these days). Calling a meeting is frowned upon as it takes up lots of time, so out of necessity, most communication occurs over email or IM. As Alistair Cockburn pointed out a long time ago, these are pretty ineffective channels of communication. Relying solely on these types of channels only turns to a build up of frustration as issues go unheard by the right set of ears. In traditional environments, these often turn into build ups set to explode at the most random of moments.

Image from Nic Jacka’s flickr stream under the Creative Commons licence

Perhaps you’ve seen it? Think about when one person hijacks a meeting to highlight an issue (typically important one) not being addressed, or when someone spontaneously shouts at someone for no apparent reason. It might even be as bad as someone having a temper tantrum, literally throwing things across the room. Traditional environments often do not provide mechanisms as outlets for this.

Therefore, when introducing practices such as daily stand ups, planning meetings and retrospectives, the first few times you run them, expect an avalanche of unresolved issues and emotions to ensue. This is fine. Expect this from some of the quieter members as you give them explicit permission to talk about important things that need resolution where traditional structures have not given them that permission to talk about them.

Treat it as you would the opening of a previously shaken soft drink bottle for the first time. You’ll have to be ready to clean up some of the spilt liquid, but you don’t have to worry about picking up broken glass. Now that the bottle’s open, you can work to address the real issue at hand.

Comments(2)

I first read “A Community of Thinkers” that Liz, Jean and Eric published late last year. I remember thinking that I felt strongly aligned to it, yet slightly uncomfortable with the exact wording. I toyed around with some words and now, a couple of months later, I am much more comfortable with a slightly abridged version.

It isn’t enough to be a member of a community of thinkers. We can philosophise and think ourselves to death. The world continues to operate in complex ways (yes, as in this, and this sort of complexity). It is not enough to sit back and only think. We need to experiment. We need to apply. We need to practise, then reflect and feed those learnings back into our thinking. This is the essence I respect the most about certain people in the agile community. This is what I want to keep alive. Remind yourself the Do is an important part of PDCA just as much as Check (Reflect) is.

For me, I am not just a member of a community of thinkers. I am a member of a community of thinking practitioners. If you’re not practicing and actively thinking, you’re not part of my community.

A Community of Thinking Practitioners
I am a member of a community of thinking practitioners.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

• reflect and honor respect the practitioners who make its existence possible;
• provide an excellent experience for its members;
• support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
• exemplify, as a body, the professional and humane behavior of its members;
• engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
• embrace newcomers to the community openly and to celebrate ongoing journeys; and
• thrive on the sustained health of the community and its members through continual practice, reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinking practitioners. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

This one is based upon the original posted on Liz Keogh’s blog here. This licensed under the Share Alike Creative Commons License. All modifications/addendums I made are emphasised in italics.

Comments(3)

I’ve been a big fan or Real Options since I heard about them a few years back. It gave me a better way of calculating the Last Responsible Moment. I look at decisions very differently now, recognising when we need to make decisions now, and when we can defer those decisions until it is too risky to make them.

Looking at the agile toolkit of index cards and sticky notes, I’ve come to realise using these during facilitated discussion is a great way of implementing real options when it comes to organising ideas.

Compare this situation:

Situation 1: The team sits in a room with a facilitator helping the team brainstorm ideas to a problem they have. As a team member thinks of an idea, they call it out, waiting as the facilitator kindly writes it up on a flipchart using a permanent marker. The facilitator then looks at the flipchart, inviting people to make observations. They comment about seeing a pattern, so the facilitator uses a different coloured pen to start drawing lines between ideas. They try crossing out ideas, rewriting them closer to places that seem more relevant. As more discussion ensues, the board becomes covered in more lines, rewritten words, and the facilitator becomes flustered with people changing their minds all the time. Out of frustration, the facilitator stops the group and asks them to make up their mind for the final time.

Situation 2: The team sits around a table in a circular format, each with a pile of sticky notes and markers in front of them. As each person thinks of an idea they write it down on a single sticky note and put them into a pile. The facilitator takes the sticky notes, and starts to arrange them on a wall. The team notice a pattern, moving certain sticky notes closer to each other. More discussion ensues and everyone suddenly helps moving, grouping, sometimes ungrouping ideas as they experiment to best find how the ideas relate to each other. The facilitator stands back at the end of it, and takes a photo to share as the outcome of the meeting.

Deferring commitment using sticky notes
I love using index cards and sticky notes as they let you capture ideas and move on before needing to classify, categorise and relate them to each other (somethign you can spend a lot of time on). They let you experiment cheaply seeing structures in the ideas by moving them around. Rather than being restricted by a piece of paper (flipchart), your only restriction on experimenting is the time you spend on rearranging and looking for patterns. Sticky notes (or index cards) allow you to defer the commitment of linking ideas together in a model. In my experience, even if you substituted a whiteboard, you spend more time rewriting (recapturing) ideas than finding ways to relate them to each other.

Comments(0)

Thanks to all the people who came along to the GeekNight Liv Wild and I hosted last week. We’ve put the slides up online here.

Comments(0)

I hear about two major approaches to introducing agile methods to organisations. Kaikaku (known in lean circles as radical change) is the brute force method of pushing all the change you want upon the organisation. You recognise this when basically the “normal” way of working is flipped on its head and a whole swarm of new practices are introduced.

Kaizen (known in lean circles as continuous improvement) is the softer, gentler approach to change, tweaking one bit here, and one bit there. Think of this as a way of introducing a single practice a time.

Now that we are clear about what is what, comes the interesting question of what is better?

You seem to be faced with two choices. A radical change that seems like a high chance of failure, but could also be a huge success, or smaller incremental change to do this.

In order to answer this question when I join a new team or organisation I like to consider how much their environment supports them in what they want to do. Those with supporting, nurturing or safe environments I would probably head towards Kaikaku, using education and building trust with senior stakeholders to establish longer term safety. You can increase safety and reduce the likelihood of failure if you can bring in a high proportion of the culture you’re looking for. I’ve seen this succeed really well when you have at least 50% of a team with lots of agile experience, something you tend to have when you hire someone like ThoughtWorks.

Work with less than 50% experience mixed support, and you start to decrease safety. At this point, I would start to look towards kaizen methods of improvement. Of course there are many levels at which you might apply kaizen and kaikaku, but consider safety levels when doing so.

Comments(3)

More interesting developments as @carlton858 points out there doesn’t seem to be a Professional Scrum Master certification announcement on the home page of Scrum.org anymore.

Fortunately I still had a copy of the page as it looked yesterday below:

Here’s what google’s cache of it had several days before that:

And here it is today:

I’m intersted to see what future developments occur in this Scrum world. Here’s the original PSM announcement. (bearing in mind it’s probably going to change or not be relevant when it comes back up)

Comments(0)

The split in the Scrum community with Ken Schwaber going independent of the Scrum Alliance sees Scrum.org announce the Professional Scrum Developer program.

An interesting development indeed. There’s also now a competing certification for the Professional Scrum Master instead of the Certified Scrum Master. I’m sure this is going to be confusing for everyone. (I wonder if that means Certified Scrum Masters are then implied as Unprofessional as a result?)

Comments(4)

A few weeks back, Andy and I got together to walk through all the different iPhone examples that we’ve been playing around with. We both learned a great deal.

I’ve found that teaching whilst learning is actually the most effective way of learning. There’s something about trying to put words to the things that you think you know that makes you reason actually how little you really know.

I think the best learning model where this experience fits in is the following model:

Unconscious Incompetence -> Conscious Incompetence -> Conscious Competence -> Unconscious Competence

The act of trying to explain something is trying to raise you from one level to the next. If, for instance, you think you know what you’re doing and then find yourself having difficulty explaining something, you’re perhaps you are at a stage of Unconscious Incompetence. However if you know you are already incompetence (Conscious Incompetence), then the act of explaining is helping your understanding, testing the boundaries of where your knowledge fails. You are trying to move from Conscious Incompetence to Conscious Competence.

Interestingly, articulating your competence (or lack of) is an integral part to both a software craftsmanship model and pair programming, where in both you are expected to articulate your reasoning. The benefits work at all sorts of levels including the novice-novice and even the expert-novice pairing arrangement.

Comments(5)