thekua.com@work

One of my biggest annoyances when it comes to testing is when anyone reaches for a mock out of habit. The “purists” that I prefer to call “zealots”, are overwhelming in numbers, particularly in the TDD community (you do realise you can test drive your code without mocks?) Often I see teams use excuses like, “I only want to test a single responsibility at a time.” It sounds reasonable, yet it’s generally the start of something more insidious, one where suddenly mocks become the hammer and people want to apply it to everything. I sense it through signals like when people say “I need to mock a class”, or “I need to mock a call to a superclass”. Alternatively it’s quite obvious when the number of “stub” or “ignored” calls outnumber the “mocked” calls by an order of magnitude.

Please don’t confuse my stance with “classical state based testing purists” who don’t believe in mocking. Though Martin Fowler describes two, apparently opposing, styles to testing, Classical and Mockist Testing, I don’t see them as mutually exclusive options, rather two ends of a sliding scale. I typical gauge risk as a factor for determining which approach to take. I believe in using the right tool for the right job (easy to say, harder to do right), and believe in using mocking to give me the best balance of feedback when things break, enough confidence to refactor with safety, and as a tool for driving out a better design.

Image of broken glass taken from Bern@t’s flickr stream under the creative commons licence

Even though I’ve never worked with Steve or Nat, the maintainers of JMock, I believe my views align quite strongly with theirs. When I used to be on the JMock mailing list, it fascinated me to see how many of their responses focused on better programming techniques rather than caving into demands for new features. JMock is highly opinionated software and I agree with them that you don’t want to make some things too easy, particularly those tasks that lend themselves to poor design.

Tests that are difficult to write, maintain, or understand are often a huge symptom for code that is equally poorly designed. That’s why that even though Mockito is a welcome addition to the testing toolkit, I’m equally frightened by its ability to silence the screams of test code executing poorly designed production code. The dogma to test a single aspect of every class in pure isolation often leads to excessively brittle, noisy and hard to maintain test suites. Worse yet, because the interactions between objects have been effectively declared frozen by handfuls of micro-tests, any redesign incurs the additional effort of rewriting all the “mock” tests. Thank goodness sometimes we have acceptance tests. Since the first time something is written is often not the best possible design, writing excessively fine grained tests puts a much larger burden on developers who need to refine it in the future.

So what is a better approach?
Interaction testing is a great technique, with mocks a welcome addition to a developer’s toolkit. Unfortunately it’s difficult to master all aspects including the syntax of a mocking framework, listening to the tests, and responding to appropriately with refactoring or redesign. I reserve the use of mocks for three distinct purposes:

1. Exploring potential interactions - I like to use mocks to help me understand what my consumers are trying to do, and what their ideal interactions are. I try to experiment with a couple of different approaches, different names, different signatures to understand what this object should be. Mocks don’t prevent me from doing this, though it’s my current preferred tool for this task.
2. Isolating well known boundaries - If I need to depend on external systems, it’s best to isolate them from the rest of the application under a well defined contract. For some dependencies, this may take some time to develop, establish, stabilise and verify (for which I prefer to use classical state based testing). Once I am confident that this interface is unlikely to change, then I’m happy to move to interaction testing for these external systems.
3. Testing the boundaries of a group of collaborators - It’s often a group of closely collaborating objects to provide any useful behaviour to a system. I err towards using classical testing to test the objects in that closely collaborating set, and defer to mocking at the boundary of these collaborators.

Comments(3)

I remember reading about the Cause, Made Visible and Not Related story on Esther Derby’s blog a while back. My biggest takeaway was that retrospectives aren’t normally the Cause of issues, instead creating Visibility into the issues already present. People constantly surprise me when they say that don’t like retrospectives because it doesn’t fix their issues. Guess what? Simply holding a retrospective won’t magically fix all your issues because it isn’t the Cause of them. Yet how do you go about fixing your issues if you don’t take the time to identify what issues you have, what impact they’re having and how you’re going to fix the true Cause?

Image taken from Dr Pat’s Flickr photostream under the Creative Commons licence.

Comments(0)

I’m a big believer in letting people try things out. Unfortunately, most training programs don’t let people do this enough. In fact, most of the time, training is seen as some way of “fixing problems” or a “all-in-one solution”. I can tell you a simple reason why training fails… people don’t have support to actually use the things they are trained on. They don’t get the essential feedback loop in their real environment and they quickly forget what they learned.

It’s all fantastic when you have an opportunity in class to try what you learned out. What really matters if whether or not you have long term lasting support in your environment to apply it to what you do. Unfortunately most training programs fail to address that, or the trainers don’t feel like it’s something they can influence.

Training lasts a day. True learning lasts a lifetime. If you send people on training, make sure they have a safe environment to apply it as well. Don’t view training as a silver bullet. Use it as a tactical solution as part of a larger strategic initiative.

Comments(3)

Definitely a post well overdue (think end of March), although I thought I’d still put it out. Four years at Thoughtworks for me has:

• Taken me to four countries (Australia, United Kingdom, India, Canada). Even more if you take into account conferences and other invites (Finland, Sweden, Norway, Italy, USA)
• Let me see eight different client organisations (from small to extremely large)
• Worked on seven different delivery projects

Picture taken from BFick’s photo stream under the Creative Commons Licence.

• Advised on two pure consulting engagements
• Presented and participated at five different global conferences
• Participated in five different internal conferences
• Seen me focus on two main programming languages and platforms (Java and .Net)
• Broaden my experience as a developer, technical lead, analyst, agile coach, full time trainer, and facilitator.

There’s been plenty of happy moments, sad moments, lots of learning, lots of growth, and plenty of insight balanced with plenty of humility (in that there is still so much to learn).

Comments(4)

I’ve been leveraging my experience with agile in teams and development and applying it to what I’ve been doing in training. Here’s what it looks like:

• Review material before class - Executing the material with an audience is the slowest part of my feedback loop. Instead, I’ve had a few people review different parts of the material during and after I’d developed the material, constantly seeking people who might give a different perspective about the content, delivery techniques, etc. Some of them involved a detailed walk through, others a brief, what do you think response?
• Gathering feedback from classes - I’ve had a chance to run some pilot classes, gathering effective feedback to consider changes. I also try to set some time aside after class, capturing notes around how effective I thought some of the classes ran, looking at ways of improving them.
• Eating my own dog food - The trainer’s guide is meant for someone else, and as difficult as I find it is, following a guide you wrote, I try using it to plan out the classes I run to see how well documented it is.

Comments(0)

I’ve pondered on a question from the last Retro Gathering where someone asked how do you prompt people to tell their story by starting them with a common seed. I’ve thought about a couple of them since then, and got to run a new exercise with some people at the Calgary Mini Away Day we just had (thanks all for participating!) This exercise was inspired by the childhood TV show in Australia, of the same name (Mr Squiggle). Kids would literally send in a set of squiggles to the show to be put in front of a blackboard, where the main character, a puppet with a pencil on his nose, would turn them into complete drawings. See this link if you want to know more.

What is it: A variant of the Art Gallery exercise except using a common drawing to start the creative juices.

Time needed: 10 minutes

What you need:

• An index card per participant prepared in the same way (see below)
• A marker pen

How to run it:

• Before the retrospective, prepare each index card by drawing a set of symbols on it (I started with two lines and a circle)
• Hand out the cards
• Explain that you all have the same set of symbols and you would like everyone to spend the next five minutes turning it into a picture that represents the state of the project
• After five minutes, ask participants to share their story with the group

Tips for facilitating Mr Squiggle

• Ask participants to avoid writing words as this exercise is meant to be a visual, creative process.
• Provide other colours and markers to help with the creative process.

Summarising:
Mr Squiggle brings a different take on the Art Gallery picture at demonstrating how a simple set of symbols can be converted into completely different stories when explained by participants.

Comments(2)

Ajit and I ran a mini-retrospective for one of the inception activities we just finished. We kept it simple, skipping a safety check, and running a simple two column Prouds/Sads activity. It lasted about twenty minutes and we came away with some key learnings that I know have helped at least one other person since then, making the time completely worth it.

We focused on a short brainstorming phase, noting items for both columns and skipped sticky notes all together, writing them directly on to a whiteboard wall. We then moved into a discussion phase talking about what we wrote up, noting additional ideas as we talked about them. We focused less on action items, and focused on mining tips and ideas that other people running inception activities might benefit from.

We ran it extremely informally since we’ve both used these practice many times before, and share a high degree of trust and safety. If I’d been working with someone else who I’d never worked with before, or someone who’d never participated in a retrospective, I would’ve looked much harder for an independent facilitator and suggested a little bit more structure. I think this was only possible because we’d been through the ritual many times before, and the frequent practice helped us tap into the more effective parts much more quickly.

Comments(0)

I’m back from holidays, having been disconnected for the last ten days or so. I’ve finished uploading my holiday snaps (check them out here if you like) and checking all my emails so it’s time I got around to reflecting back on last year and what this new year may hold (even if it’s just that little bit late). I don’t do the whole New Year resolution thing although I try to revisit what goals I have.

In terms of conferences…

• I attended the Retrospective Facilitator’s Gathering held in Phoenix this year that continued to fuel my existing passion for one of, what I consider, one of the most effective agile practices. It’s helped me communicate even more with people about my passion for the tool, continued to refine my approach and understanding of the tool and helped others to see the value they add. It’s also put me in touch with a whole heap of other people that share this similar passion. I’m sometimes referred to as *the* retrospective guy in the UK office and even though I don’t agree with that statement (I don’t know everything there is to know about retrospectives, and I’m certainly not perfect at running them - I’m just passionate about them). I’ve even helped to organise this year’s gathering.
• I helped Tom Sulston out with his workshop, The Daily CI and I ran my Reface Your Team Space session at XP2007 in Como, Italy. Though I enjoyed the two sessions, I thought last year’s conference ran much smoother and had much better content than this year’s.

In terms of writing…

• I published my first article on InfoQ after writing a series of blog entries on Onboarding Strategies. I want to continue to add and refine these as I still think there’s important lessons here that I hear teams fail to do everyday.

In terms of opensource…

• Even though I’d contributed patches and bug fixes to some projects, last year I released my first real open source project, an API for printing to Zebra-branded printers written in .Net called Sharpzebra. I’ve hosted this project on Codeplex and I hope it eases someone else’s problems printing to this proprietary language.

In terms of growth and lessons learned…

• I’ve read much more on Lean and Theory of Constraints this year, and starting to feel like I have a better grasp of the concepts. Applying them in a practical fashion in terms of noticeably different practices is the much more difficult step I need to take next. For other people’s reference, read books like “The Goal”, “The Elegant Solution”, “The Toyota Way”, “Lean Thinking”, and “Toyota Talent”. I’m sure there’s much more to read as well.
• Only eight months after a disappointing situation, I finally made it to India to help conduct some training, giving me a full time focus on coaching, training and facilitation techniques. I also have to thank one of my fellow trainers, Rixt who’s been fantastic at helping me to be more aware of many other techniques and approaches that I then could practice and apply during the training sessions. I feel that the delivery methods for the course improved significantly over the three months the whole training team worked together on.
• This year I also first officially lead (at least from a technical point of view) an all TW team, and under fixed bid conditions, high expectations from the client and a very complicated domain with a few new people, delivered a very successful project to a very happy client. Reflecting on the experience, I extracted out many of the onboarding strategies I wrote about, and then applied it as the team almost doubled in size for the next release.
• I’m also very proud of the way, as a team, we handed the leadership over seamlessly to another person as I prepared to head to training. Transitioning the tech lead role is often executed haphazardly, leading to inconsistent visioning, confusion amongst the team and general chaos. I’m pleased that when I left the team, it was like they could work without me (which is a good place to be!)
• I stayed at the same client for most of the year, although ended up on two different projects - one of which I worked on the year before. Seeing the same project, or introducing new people to the same project months later taught me so many lessons about what decisions or approached work or don’t work taking a long term view of a project. I can’t recommend it enough to anyone to make sure they understand the consequences of the choices they make beyond their own time on the project.
• Tim Bacon (an alumni Thoughtworker and fellow agilist) introduced me to the Amplify Your Effectiveness crowd that seems to align strongly with members of the agile community. That, and the Getting Things Done crowd.
• I created two new retrospective exercises, one that I’ve blogged about called The Three Word Starter, and another I’m yet to blog about though I tried with a couple of teams in India.
• It’s not about what models you use, it’s about how you use them. This year, I’ve learned so many different models from so many different people, and although they appear trivial, watching people who really harness their energy constantly amazes me. I need to remind myself, it’s not about whether or not a tool is good - it’s how it’s used and how it’s applied.
• Doing the things you say is much more powerful than simply saying things. It demonstrates commitment, and belief in the things that you value and is often an effective way of leading change in teams. I’ve seen people say things and then do something completely else, confusing people to no end. Others simply say things and don’t do anything about it, making it less likely to occur.
• Effective feedback earlier is better than no feedback at all. It’s better than feedback too late to do anything to do with it. Of course, this takes energy yet it’s a very powerful thing if people respond to the feedback (it’s not always guaranteed). You can do at least your part by ensuring the feedback is timely, and well constructed.

Comments(0)

I’ve really enjoyed my time facilitating and training experienced co-workers. It’s a great opportunity to share some of my stories and given me some time to focus on really refining some skills and deepening my knowledge as a coach and facilitator. I’ve learned some important lessons that future trainers or coaches may benefit from.

Balance your energy
A day of successful training should leave you with that satisfying yet slightly exhausting feeling. Presenting, facilitating and responding to the needs of the class take energy and students respond well when you demonstrate your own passion for it. Putting this energy into all your sessions will take its toll and makes you susceptible to falling ill. For my first two training courses, I fell ill immediately the week after and I’ve noticed this same cycle with the other trainers.

Find your sustainable pace by understanding your own limits, getting enough rest, and spending enough time on yourself to recharge. The alternative of a lethargic, sick, trainer running a class is definitely not effective.

Learn about learning
Training experienced hires brings a different dynamic compared to those straight out of college or university. The vast array of backgrounds, different working experiences and varying degrees of openness to the material requires a more versatile approach to the material. Understanding everyone’s different learning styles, and understanding different models equips you with better techniques to help everyone in the class learn.

Learn about things like Shu Ha Ri, the four stages of competence, Visual-Auditory-Kinaesthetic approaches, Kolb learning models,

Avoid sticking to the same training technique (such as lecturing) as it gets boring (and ineffective) very quickly.

Work as a training team
We work as a team of Subject Matter Experts (SME) and trainers with a background in training. Each role brings different aspects and understanding how to bring out both during a session is important. Respect the trainers that bring with them a plethora of training techniques, and (more likely) a deeper understanding of learning models. Respect the SME who brings the material to life with their own personal stories and (more likely) a deeper understanding of the material and its relevance to the real world.

Find ways to work together and to be able to support each other during a session. Use special signals or cues to allow seamless flows between each trainer.

Become aware of your own biases
I think it’s important to separate what people say, and how you feel about it. An important part of facilitation and training is ensuring everyone is listened to. Immediately reacting to a student’s comment doesn’t do this and the level of participation will drop off. Encourage contributions by first acknowledging their comment - “What I hear you say is … Is this correct?” Separate the observation from the evaluation.

Read the book on Non Violent Communication as it explains it much better than I do.

Comments(1)

On one project I’ve been on, all the tests began with the word “should”. Though not necessarily taking on full on BDD using anything like NBehave or JBehave, I think the simple effect of reframing tests using the word “should” worked wonders on this particular project.

We had quite a lot of people pass through the project over a year and a half, so I found it interesting to see what impact it had on tests. I observed that:

• People focused on understanding intent first, and followed through with how it was implemented.
• People had better conversations around differences (the test name said it should be doing this, and it’s actually doing this. They asked questions like, “Is the name of this test wrong, or is the test incorrectly implemented?”
• The statement is not as strong as assert or must so I felt people could challenge it more, leading to better quality conversations. “I though the domain was supposed to be like this, and the test and the code does this - Am I misunderstanding something?”

I think this subtle focus brought many qualitative benefits that I think a lot of projects could benefit from.

Comments(0)