Featured in
Architecture & Design

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Process & Practices

In-App Subscriptions Made Easy

There are various types of subscriptions: recurring, non-recurring, free-trial periods, various billing cycles and any possible billing variation one can imagine. But with lack of information online, you might discover that mobile subscriptions behave differently from what you expected. This article will make your life somewhat easier when addressing an in-app subscriptions implementation.

Featured in
Operations & Infrastructure

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Enterprise Architecture

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Experience Report: Beginners and Experts All Benefit in Open Space

Mixing up experience levels creates a valuable event for everyone.

Agile conferences are receiving an influx of novice teams and managers - the Agile 2006 conference saw an increase of 50% from the prior year. Perhaps out of concern over conference size, some suggest that new conferences should be organized for these beginners, but this strikes me as missing the point - when we self organize, diversity is an asset. I collected these observations about an interesting session at one Open Space event in order to share a concrete example of how mixing up expertise levels creates a valuable conference experience for all.

This autumn at XPday Montreal 2006 a lively bilingual Open Space event unfolded on a rainy Saturday morning. Le CRIM's main room filled up, despite the early hour, and soon I was helping Laurent Bossavit "Open the Space". Our topic: "They Do Things Differently There - Customers, Developers, Testers Learning Each Others’ Languages." After laying out the simple rules by which Open Space operates, I practically had to jump out of the way as people rushed up, and even stood in line, to share their topics and questions, inviting others to join them in conversation. After that, the day unfolded "the only way it could have," with people wandering from room to room, attending tutorials, pairing or chatting in the Project Room, and joining (or creating more!) Open Space discussions that interested them. As it turned out, the OS agenda, which we'd feared might be sparsely populated, was just jammed with topics, and many interesting conversations ran in parallel in different corners of the main room, all day long.

One session which stands out in my mind was the Mock Objects session, proposed by relative newcomer Brian Di Croce whose blog boldly states "I'll receive my Bachelor's degree (B.Eng.) in 150 days, 18 hours and 8 minutes." Contrast this with the experience level of others attending his session: Chris Stevenson was one of the original committers on the nMock project (an implementation of MockObjects for .Net), and both Amr Elssamadisy and Warren Oliver have extensive experience using Mock Objects. What got my attention was the intensity of that session - everyone seemed engaged, and afterwards all spoke of having enjoyed it... saying that the wide range of experience levels contributed greatly to the quality of that discussion. This multi-expertise-level experience connects with several topics under discussion right now in Agile forums: Should we have separate conference tracks for experienced and novice attendees? Would a higher profile for Open Space give people a chance to get more from conferences?

A mock object gives the developer a mechanism with which to abstract away the details of collaborating objects. Use of mock objects promotes code decoupling and ensures objects adhere to encapsulation. Mock objects are also easier to use with a 'tell, don't ask' style of programming, which makes code more readable and thus more self-documenting.

Mock objects are invaluable for Agile teams using Test Driven Development (TDD). One common usage is to "mock out" database or other slow service calls in unit tests: this keeps the tests running fast and sets expectations for how these services will be used.

Deborah Hartmann for InfoQ: Brian, why did you propose the Mock Objects session?

Di Croce: In one of my internships, I was lucky enough to participate in the development of a great .NET mocking tool called POCMock. Before that, I have never heard the term 'mock' preceding the word 'object'. And little did I know that it is a very powerful technique to adopt in some special scenarios involving unit testing. From the personal research I've done about it, not a lot of people know about this testing technique; and if they do know about it, it is sometimes used inappropriately. Therefore, I told myself "If I'm going to talk about something [in Open Space], it might as well be something that can improve one's productivity and ability to develop better software."

InfoQ: Do I correctly recall the word "Help!" written on your topic card? :-)

Di Croce: Yes, yes! 'Help'... I love that word! I was actually challenging the ThoughtWorks (TW) guys to participate in the session, mainly because TW is behind many great open source tools, e.g., nMock. And you know what? It worked! Both Warren Oliver and Chris Stevenson (he's an active developer in some of these open source tools, including nMock) from TW, and Amr from Valtech, provided many thoughtful insights, tips and honest opinions when answering the fundamental questions (what is a mock object? why should we care? how do we use this technique? etc.). I knew my knowledge in that area was limited, so when I saw those remarkable people in the room, I couldn't let the opportunity slip away; I had to ask them for their valuable help during the session.

InfoQ: How did you feel about the way the session self-organized?

Di Croce: It was great! The participants were humble and respectful when trying to answer the questions. I would summarize the session in one word: collaborative. Very collaborative.

Warren Oliver of Thoughtworks and Amr Elssamadisy of Valtech Consulting were also participants in this conversation. I asked them about the session - how was it to attend this session, since they both have plenty of experience with the subject?

InfoQ to Warren Oliver: Why did you attend this discussion?

Oliver: Over the last 3 years I've been trying to master the skill of TDD, and a big part of that effort has come in the way of learning the best use of Mock Objects. I've learned so much and come so far that I thought I could really help Brian understand how mock objects can help you develop in a TDD way. I think you can also get a feel for how much you really know on a subject when you have to try and explain it to someone else.

InfoQ: What did you contribute? What did you get from it?

Oliver: I was able to share my experiences with using a variety of mock object tools such as EasyMock, NMock and Rhino Mock. I think as a group we were able to collectively address the questions of the session, what, how, when and why. I picked up useful tips on when to use the object mother testing pattern. Mock objects are useful, but not in every situation. Being able to identify a situation where they are not useful is a good skill to have.

I thought it was a great session where all parties seem to get something from it, included the more experienced. The session had a lot of energy and I think that had a positive impact on Brian.

InfoQ to Amr Elssamadisy: Did you find the session valuable?

Elssamadisy: I found the discussions with the more experienced people useful because we had a shared background in testing using Mocks and ObjectMother. We did not always agree – but the information exchanged was valuable. It would not have been as valuable if there were not less experienced developers at the table. They forced us all to explain the issues from first principles in order for everyone to be involved in the discussions. This cleared up miscommunications between the experienced attendees. They also kept us from veering too far astray in the topics and coming back to the basic questions of when and why to Mock. So, all in all, the mix of experience in an open space session was very positive.

Perhaps because of the event's theme, we had a very heterogeneous collection of participants at XPday, and yet these positive experiences were echoed all around the circle, when we "closed the space" at day's end. And, in addition to building knowledge about specific topics, this event also built valuable relationships between like-minded colleagues - people who might not have discovered their common interests, had they been sitting silent in "talking-heads" sessions all day. (XPday did include such tutorial sessions, and participants were free to wander from one mode of teaching to the other). XPday Montreal's Open Space started conversations that continued in the pub later that evening, on the train on the way home, and by email and in person in subsequent weeks. The consensus was: "let's do this again!" despite vast differences in experience levels and job roles present at the event.

The final word goes to Di Croce, who started it all:

I'd like to say to people that it's okay to ask for help or assistance for any given situation, mainly because there is so much a human being can know and vocalize. And also to encourage them not to be shy when there's something they want to say, especially if they want to share an idea that can be very helpful, rewarding or valuable to an individual. I'm very grateful to people who step out from their shells and decide to take action in delivering something useful to the community; just like it happened in the Open Space.

Open Space, by giving the event back to the participants, suddenly benefits from a room full of intelligent organizers. It seems to magically generate ideas and collaborations which a few hours earlier didn't exist. In Open Space, distinctions between "novice" and "master" are not pertinent - with each change of session, people are free to choose between "student" and "teacher" roles, as they wish - and both roles contribute equally to the value of the event. Because it is created by the very people who need to find answers, the questions are germane and the sessions are passionate. This self-organization explains how the Open Space technique has adapted equally well for use by businesses, interest groups, and non-profits, and for groups from 5 to 2000 people, with great success for over 20 years. It's not the only way to learn... but for key questions not answered by lectures, when creative discourse is preferred, or when relationship building is important, it provides a simple structure within which these needs can be met.

About the Author

Deborah Hartmann is a Toronto Agile Coach, passionate about making work valuable and rewarding, who thrives on helping teams and their customers discover the best ways to do this. With over twenty years' experience in the IT industry, she knows that process can help or hurt a team. She uses practices like Scrum, retrospectives and Open Space to help people get productive again by tapping into and leveraging their own collective wisdom. Deborah is an active contributor to both local and international Agile communities, most recently at XPToronto and at the Agile2006 and NoFluffJustStuff conferences. She is a member of the XPday North America team, facilitating the Open Space track at XPday events in Canada and the US. Deborah has been the Agile Community editor for the InfoQ.com Enterprise IT Community news portal since its launch in June of 2006.

There I was, in the same building, and I didn't attend that session. What a shame!

At the Simple Design and Test conference (stdconf.com), we had a similar discussion, when someone asked "Why do mock objects feel so clunky?" Although we didn't get to write any code, I think we left the session's proposer with some better ideas how to proceed in the future. I offered to pair with him anytime--we'll see whether he takes me up on that.