Lunar Logic Polska Blog

The Four Dimensions of Software Quality that you can't afford to ignore!

2012-03-06T13:14:00Z

One of the practices espoused by kanban teams is to "make rules explicit." However, after asking several times in forums and on Twitter "How do you make rules explicit?" without ever receiving an answer, I am inclined to suspect that many teams don't, in fact, have a good way of capturing and sharing team rules. At Lunar Logic, we're big fans of BVCs (Big Visible Charts) and our walls are covered with information radiators in the form of charts, graphs, and process lists. We're also passionate about software quality, and so I'd like to share some of our QA process tools that serves as one way in which we make rules explicit in our teams.

Ask most people what software quality means, and you're likely to get an answer related to the absence of "bugs" in which bugs are usually defined as features that don't work. Too many software teams primarily address this facet of quality by eradicating bugs. That's all well and good, and the world would be better if we could find and fix the many bugs that live in our favorite software, but this is a woefully incomplete picture of software quality.

The four dimensions of software quality that we've identified are these:

Well-structured, cleanly-written code with good automated test coverage which is easy to work on and follows standard conventions and coding practices with clear style guidelines that are consistently followed.

This allows new people to join the team or for a product to be handed off to new team easily. It makes it easy to add new features or to refactor code without fear of breaking existing functionality.

Good design with an architecture that allows for efficient and appropriate scalability.

Not every web application is going to have to support millions of users, but just in case the architecture should be such that migrating to cloud hosting or to a distributed delivery model shouldn't involve massive refactoring.

Excellent quality software is a pleasure to use.

It's not enough that the features work; they should work in a way that is intuitive and pleasant for the users.

And finally... in high quality software the features work as intended

Without awkward workarounds or… bugs. This doesn't just mean that the feature isn't broken, but also that the need was clearly understood and appropriately addressed by the development team.

Every project team has its own way of ensuring high quality in each of these four areas, although some practices are embraced by everyone in the company based on experience: all teams at Lunar Logic do pair programming and have peer code reviews on all commits. Architectural quality is reviewed periodically by having cross-team code reviews. Hallway testing new features and design changes helps to address usability issues early.

We tailor new practices according to a particular product or environment. The important thing is that every team is thinking about standardizing a set of quality practices that maximizes software quality in all four dimensions so we don't end up with a product that looks great, but doesn't work, or works great, but doesn't scale.

What you might notice is that in no place in this article have I referred to software testers, or QA engineers. We have them, of course, and we highly value the perspective and skill set that such professionals bring to a team, but it's important to remember that software quality is the responsibility of everyone on a software team, and team QA practices reflect this fact.

Using the chart

To emphasise the importance of other dimensions of software quality, at Lunar Logic we collect practices on a wall chart with four quadrants.

We print this chart on A0 paper (that's a big poster size) and put it on the wall in a team room. Proposals for quality practices that come out of retrospectives are added using post-it notes and if they prove to be good ideas, they are written on the poster. These practices should be detailed enough to be consistently followed. For example, rather than "hallway testing" we might write "When a programmer has finished work on a feature, she asks someone who’s not busy to use the feature without guidance or prompting in an IE environment before the feature is marked as ready for a code review." Making the rule very specific in regards to who does what and when makes it far less likely to be ignored or sloppily implemented.

How do you make QA practices visible and keep them evolving?

Here's the wallboard chart in case you'd like to use it!

How to Automate your Retrospectives!

2012-02-20T11:55:00Z

I've been intrigued by the idea of self-guided retrospectives. Imagine motivated teams that could collect and evaluate data and reach valuable conclusions without management guidance! It appealed to me in more ways than one - firstly, to my principle of empowering teams wherever I can. It also suits my personality. I'm an introverted control-freak, which means I risk manipulating situations even when I'd really rather not be involved at all. I've come across techniques by which teams could progress through a retrospective themselves, but I face the added complication that many of our projects have at least one remote team member, because our clients are usually in America or Western Europe. I seized on the idea that Kanbanery, our web-based project tracking tool, could be used to facilitate the kinds of interactions that lead to a valuable retrospective.

Our retrospectives with distributed teams were always very traditional, with either no interaction with physical objects (discussion only) or with a local proxy assisting remote participants. There's value in collecting ideas on cards and manipulating them as a group, but I don't like the necessity of treating remote team members differently.

Teams in Lunar Logic are using Kanbanery’s real-time updates features to collaborate effectively. Could we use the same familiar tools to hold a retrospective session? The answer came when I applied a TRIZ technique of reducing the environment to its bare essentials and asked what I had to work with within the constraints I set. If you're of a more philosophical bent, you might say that I asked of Kanbanery: "What is this thing in itself?"

Kanbanery is intended to visualize the flow of work through a process but essentially it is just a series of lists of items which can be moved between columns, both horizontally and vertically.

Items have certain distinguishing features that help organize your work:

A title field with a larger description field,
The avatar of the last person that handled them,
Checklists, type fields, and check marks just in case you need them.

as well as a variety of other features that weren’t required while preparing for a retrospective.

A Kanbanery-powered retrospective

Thinking of Kanbanery as a series of lists gave me the clue I needed to devise the retrospective exercise.

Newly created tasks appear in the first column, so I called it the ‘Working’ column. I labeled the next column ‘Retrospective Steps’ and in it I placed the instruction cards for conducting the retrospective. There are many methods of conducting a retrospective, but my favorite is to collect data from team members about the recent history of the project, evaluate their answers, extract useful practices and discard those that were unhelpful and finally to choose a small set of those changes to implement in the next iteration. I created columns for each of these steps.

We used this process for our last Kanbanery retrospective, which I joined from home while I was ill. Here is how it works. The team members sit at laptops in a room together or in their own offices and start a live call via any teleconferencing system (we used Skype). Because of the shared Kanbanery board, all team members are equal and interact with it in the same way.

The team begins to work through the steps listed in the Retrospective Steps column:

They set a timebox for the meeting and write it down in the title of the first card, so everyone knows when the meeting will end,
Everybody reads and all agree to the retrospective prime directive,
Team creates the project history by adding cards and dragging them into the History column in chronological order.

The advantage to using Kanbanery is immediately visible - everyone contributes in his or her own way and time without biasing others. Cards begin appearing like "Got our first paying user", "Migrated to new test server", and "Marcin joined the team". The avatars show who added which tasks.

When the time is up, the team members use the checkmark feature to mark the events in the history that they feel good about. The team can talk over, point by point, any ambiguities during this stage.

Afterwards the team, with the history fresh in their minds, brainstorms about the useful practices that might be associated with the highlights of the recent history, about unhelpful practices that might have led to the pitfalls they faced, and to practices they'd like to consider adding or changing to make future iterations more effective. They do this in the same way in which they built the history, by creating cards with ideas in the Helpful and Unhelpful Practices column.

Next the team talks about the practices listed and agrees on three (or any other number) which they will change going forward and they drag these to the final column, What We Will or Will Not Do. The team can look at these decisions and clarify them in terms of how they will be implemented, by whom, and when. After reaching an agreement, they can capture these ideas by using Kanbanery's “Export to PDF” function to print the decisions onto index cards easily put on the wall.

Though I participated in the retrospective as a remote member, not only was it a very focused and well-organized retrospective, but also I felt I was actively participating because I could create my own tickets in just the same way the other team members were. The meeting stayed on time, each phase was clear and moved us inexorably to useful conclusions.

Ideally, retrospectives are very interactive activities that take place with everyone in the same room, finding solutions and exposing truths hands-on with appropriate visual tools, but that’s not always possible in this day of remote work and global teams. Here’s a new technique to add to your remote development toolkit. Let us know how it works for you in the comments.

Navegas: Connecting the World of Music

2012-02-06T13:43:00Z

Working on a project with a strict deadline that isn't too far away isn't something that we developers like to do, to put it mildly. So when Lutz Villalba-Adorno, a German entrepreneur, contacted us in December with a project that had to be ready for the Midem music conference on 28th January, we knew it was going to be a challenge. But the project just seemed too interesting to refuse…

The application, which was originally implemented by another company from Poland, is called Navegas and is a web-based music player that lets you easily play music from various online sources, arranged in a single playlist. Currently it supports YouTube and SoundCloud APIs, and also a new Berlin-based online radio service called Aupeo which we've integrated; additionally, you can mix music files from your local disk with those from the web. The app currently has full support only for Chrome, although most features should also work in latest Firefox and other modern browsers.

We knew from the beginning that we wouldn't be able to add every feature and improvement we wanted, so we had to keep it simple and focus on the essentials. We've determined the set of features that were the "must haves" – e.g. the Aupeo integration, new design or the social sidebar which finds links to music videos posted by your Twitter or Facebook friends. We had to constantly remind ourselves that it's logistically impossible to do everything in time – it was sometimes painful to ignore some nice ideas for improvements, but it was the only way we could meet the deadline.

There were some technical challenges too. For example, the Aupeo API is very fresh and we were probably the first ones apart from its creators to use it, so there was no open source code available and we had to write it ourselves. But there were also some bright sides – you can't really complain if your work not just allows but actually requires you to listen to music all day :)

Fortunately, we managed to get everything ready in time before the conference, and Lutz could proudly present the new version to the attendees. The app has now more features, looks much better than it did before, and it works faster. We even managed to make the code a bit more maintainable in the meantime, which, as you may know, is especially difficult when you're working under time pressure and there's a constant temptation to cut corners to finish the work faster.

Overall, the project was a great success – we all had a lot of fun working on it, we've learned a lot, and we'd love to do that again in future. We're also hoping more users will start using it regularly – some of us certainly will!

Like in real life, your second big love is even better! The folks at LLP did an awesome job with limited resources (time + budget) but most importantly - inspired me and Navegas! Always again!
– Lutz Villalba-Adorno

Urban noise levels at last measurable - thanks to AirCasting!

2012-01-31T13:35:00Z

Have you ever wondered how loud, exactly, is that noisy crossroads that prevents you from having a well-deserved sleep? Is it really comparable to a herd of starting jumbo-jets pursued by a swarm of fighter planes? How could anyone put up with this madness?

Worry not - we’ve got a solution to your problem and it’s called AirCasting.

AirCasting is an Android application that measures noise pollution. It’s a light, flexible and free-for-all Android app we created for HabitatMap.org with funding from Google’s Charitable Giving Fund of Tides Foundation.

AirCasters measure sound levels, which they can choose to contribute to a crowd sourced map of noise pollution. This allows everyone to see the best place to either walk your dog, wind down and meet your mates or, simply, test your brand new protective earplugs.

All right, all right, you may say. Buzzwords don’t impress me anymore. I would like some facts. How does it work in practice?

Sound level measurement started in New York City. Its inhabitants complained about noise to a City hotline. The usual hustle & bustle affected their sleep, health and overall well-being. As a tool to justify their claims, AirCasting becomes a vessel for public opinion. Local authorities may dismiss one claim unsupported by any evidence, but what about hundreds of noise pollution reports made on the spot?

AirCasting has been developed by three Lunar Logic pros: Paweł, Marcin and Grzesiek (he was testing the app). I’ve asked Paweł some specific questions about AirCasting.

Mirek: What does AirCasting do, in a nutshell?
Paweł: AirCasting is a platform for sharing and visualising environmental data. Currently the only supported kind of data are noise levels. These can be obtained by users with their phones and then shared through our website.
M: Which parts of the smartphone does it use?
P: Most prominently we are using the microphone to gather noise level data. Other than that we are using Google Maps to visualise the data the user and others have gathered.
M: Are there any planned extensions for the app?
P: The app is planned to support a wide range of environmental sensors with which it will connect via Bluetooth. The one that's being engineered right now is a gas sensor for measuring pollutant concentrations in the air.

AirCasting has been live since 20th December 2011 and is available free from the Android market. The source code is available under GPL:

https://github.com/LunarLogicPolska/AirCastingAndroidClient https://github.com/LunarLogicPolska/AirCasting

Why we built 'Engage!' - a Rails Engine for User Engagement

2012-01-25T15:14:00Z

Most web startups struggle and many fail. For almost a decade, I've been watching it happen up close. As the owner of a custom web development agency I've had front-row seats to rare moments of glory and spectacular failures. When I encountered the customer-centric approach promoted by Steve Blank in The Four Steps to the Epiphany and more recently popularized by Eric Ries in The Lean Startup, I was excited, because it described so nicely a solution to many of the problems I've witnessed over years of watching startups launch. I've seen founders blinded by the brilliance of their own vision fail to adapt to the demands of their users and miss crucial opportunities to adapt, or pivot, in Lean Startup jargon.

The idea of the customer-centric approach is to build a product largely driven by feedback from users. This way you have a successful product that you can be sure solves real user problems.

In 2009, we built one of the first online Kanban board applications because we needed one to work with remote clients and nothing like that existed at the time. We later decided to offer the product to the public and for the first time I was the product manager of a web startup and I could apply principles I had learnt over a decade in software development. Initially, my decisions about Kanbanery were primarily driven by principles such as team empowerment, flexibility, transparency, trust, and ease of use. For the details, however, I looked to user feedback.

Getting that user feedback would prove a major challenge. What tools could be used to obtain the necessary feedback from users in order to overcome the challenges of our first product? It was in answering this challenge that the second product we created emerged: the Engage! engine for user engagement.

Like other startups, we had two alternative solutions to the problem of obtaining user feedback. The first solution was to use a hosted service such as GetSatisfaction or UserVoice while the second solution would mean developing our own support tools from scratch.

I didn't want to distract us from our main task of working on Kanbanery, so I opted for the hosted solution but frustration was quick to set in. The frustration was largely due to the same problems most companies face with the use of one-size-fits-all hosted applications, in that they offer a limited range of customization. Also, using this tool meant that users had to leave our application and create a new account on another application in order to provide feedback and this confused a fair number of users. I was also faced with an awkward financial decision. Any of the 30 people in my company might help to support users by answering questions or engaging with them in the feedback forum, but at $25 or more per person per month, I had to decide who would get accounts and who wouldn't.

We're about to change all of that with our own software solution to user feedback and engagement aptly named 'Engage!'.

'Engage!' is customer engagement tool that plugs seamlessly into any Ruby on Rails application running Rails 3.1 or higher. It can work right out of the box with a simple installation and configuration script, but it's designed to be easily extensible and skinnable. It has all the basic features you'd expect from a ticket tracking and customer support forum but no more.

If you have half an hour to spend installing it, it will just work, but if you want to add one more feature or change the style to match your site, you easily can. It will also tie into your own authentication service for a seamless user experience, or you can use it's own built-in authentication system if your application doesn't require users to have accounts.

'Engage!' is a Rails Engine, which means it's a stand-alone application that can be added to any Rails 3.1 or higher application as easily as installing a gem. The best part is, the code will be free to non-profit organizations and open source projects, and a lifetime license will be available to web startups for a low, one-time fee. You can have as many users as you like and customize it to your heart's content without ever paying again.

If you're interested, sign up at engage.llp.pl and we'll contact you as soon as the first version is ready to release. We'll let you know when you can download it for free and start hacking at it as you like. We'll only ask you to pay for it if you install it in a commercial product. We'll be inviting beta testers to use it free of charge, so please let us know if you're interested.

If you have any questions about 'Engage!' or suggestions, we'd love to hear them. Just use the comments below.

iOS development screencast

2012-01-19T11:53:00Z

Everyone at Lunar Logic is good at something. And since no one is good at everything, it's nice to be able to share the knowledge and skills.

One of the ways we do that is an internal event we call "workshops". Technically, these aren't workshops in the strict sense, but rather technical presentations with a lot of examples, where someone explains to everyone interested how to use some kind of framework or technology.

I've recently done one such workshop, titled "Introduction to iOS development". This time, we've decided to make an experiment and record it as a screencast, and share it with everyone. We think it worked out pretty well – sorry for the sound quality though, let's hope it will be better next time.

The screencast is mostly intended for people who haven't done much iOS development (or none at all), to give them a general idea what it looks like. It first shows how to generate an application from a template, what this application does and what each part of code is for. Then I quickly go through the code of an example application – a simple client for RubyTime, our time tracking webapp. I also show some examples how to use LunarToolkit, an ObjC library we've shared recently on GitHub (note: it's referred to by its old name "PsiToolkit" in the screencast). If you've already written an app or two in UIKit, you might want to skip straight to around 22:00 where the RubyTime part starts.

If you're just starting with iPhone development and ObjC code seems to you like something written by aliens, I also recommend that you read this blog post I've written some time ago, which explains the basics of the language to developers familiar with some other popular languages.

If you want to play with the code yourself, here are the GitHub projects:

RubyTimeExample - https://github.com/LunarLogicPolska/RubyTimeExample
LunarToolkit - http://github.org/LunarLogicPolska/LunarToolkit
RubyTime - http://github.org/LunarLogicPolska/rubytime

Global CodeRetreat Day - Video Report

2012-01-04T13:26:00Z

We decided at LLP that such event as Global CodeRetreat Day needs something more to commemorate it than just report and photos.

We prepared a short report to let those who weren't at the event taste the atmosphere and for the participants - to remind them of the whole day spent on creative coding.

Thank you once more for coming! You can read the report from Global CR Day and see the photos.

Notes from the 13th SCKRK meeting

2012-01-03T13:34:00Z

Software Craftsmanship in Kraków (shortly SCKRK) is a reading club that gathers every other Wednesday over a beer sponsored by Lunar Logic Polska to discuss articles and books related to Object Oriented Programming, Testing, Software Architecture and other interesting topics.

The club was founded by our own Adam Pohorecki, and over last year SCKRK, with help from Lunar Logic Polska, has organized two Coderetreats, one of which was facilitated by Corey Haines.

Last week, the club discussed an article written by Kent Beck in 1989, titled "A Laboratory for Teaching Object-Oriented Thinking". This article proposes a new method for describing and designing Object-Oriented applications - CRC Cards.

CRC card (short for Class, Responsibilities, Collaborators) is a small piece of paper, on which the developer notes a name of the designed class, the responsibilities that class has, and the collaborators, which the class in question interacts with. By limiting the space available for the description, CRC cards indirectly enforce limits on the number of responsibilities and collaborators of a class, and by making the developer specify all of the other objects the class interacts with, they help programmers used to the procedural programming style, to get rid of the bad habit of accessing global state.

We started the discussion by wondering whether the method proposed by Beck is still relevant today in the age of agile software development, TDD and pair-programming. Part of the group argued that these days, we do not design the systems upfront, and that the system design should be guided primarily by tests instead of a whiteboard. Others suggested that even if we do not design upfront, we still often stop to figure out what to implement next and how to do it, and CRC cards could be used as a part of that step of the process. There were also people who thought that this method could be used to model the system domain and help establish the Ubiquitous Language (which we learned about when SCKRK was discussing Domain-Driven Design).

Finally, Michał stepped in and suggested that "Teaching" in the article's title is there not without a reason. We all agreed that CRC cards can be a very useful when it comes to teaching programmers Object-Oriented Design and rules like Single Responsibility Principle.

Later we tried to apply CRC cards to design a solution to a problem proposed by Jarek. In this situation in a system there are Places and Users which have Addresses and the view layer of this application presents those Addresses in multiple ways, often quite similar to each other. After some heated discussion, which involved much more hand-waving than card-drawing, we arrived at a satisfactory solution: the Users and Places in this situation do not matter, only Addresses and their Formatting. We decided that the system would consist of an Address class and many AddressFormatter classes, one per possible display format.

Then the discussion started flowing towards Clean Code, and when can one accept increasing technical debt in order to get things done faster. This provoked another discussion about the Lean Startup movement, and what Obie Fernandez says about putting business value before implementation correctness and maintainability of "not business proven" features.

The meeting lasted almost 3 hours and was one of our longest and most attended meetings to date. The next meeting will take place on Wednesday the 4th of January, so if you are in Kraków and you are interested in Software Craftsmanship (or beer), be sure to come!

iOS development day – notes from the Cracow.mobi conference

2011-12-19T09:34:00Z

A week ago Polish mobile developers gathered in Krakow to take part in the Cracow.mobi conference organized by the team behind MobileDeveloper.pl and students of Cracow University of Technology, sponsored by Lunar Logic Polska.

The presentations were chosen to cover a wide range of topics, so that every developer interested in mobile technologies could find something for themselves. The first day was divided into Android presentations in one room (including a great talk about RoboGuice by Konrad Malawski from LLP), and those concerning iOS development in another. The second day included mostly talks related to mobile web development and Windows Phone 7 OS.

As a Cocoa developer, I was mostly interested in the iOS talks. The first one was done by Karol Kozimor and explained how to use threads to make your application's interface more responsive, or "snappy". Karol introduced us to Grand Central Dispatch, a technology included in MacOSX Snow Leopard and latest iOS, which uses blocks to define units of work which can be executed asynchronously in the background. Then he showed some examples of how we can use an older NSThread class together with ObjC run loops to correctly process incoming events from an I/O source. He also mentioned a recent discussion on social networks about differences in UI implementation and performance between iOS and Android.

The next talk was presented by Michał Tuszyński and was about ways to persist various kinds of data between sessions of an iOS application. The technologies he mentioned included:

NSUserDefaults, which can be used to store user's preferences, application state and other simple data
NSCache, a key-value store similar to memcache, which automatically manages memory to make sure it doesn't run out
archivers, which can be used to save any objects to binary files
Core Data, a complex data persistence framework which can be used like a database
and iCloud, a technology recently introduced by Apple for automatically syncing data between user's devices and storing it in the cloud

The talk that gathered the biggest audience was a non-technical one, by Tomasz Kolinko, who shared his experiences from making his own apps and showed some tips and tricks for independent iPhone developers to maximize the profits from the AppStore. First of all, he advised us against concentrating on the Polish market – it's simply too small to earn enough; you should instead plan to go global from the beginning, and target mainly American users at first. He gave us some SEO tips for making your app appear in the AppStore search results, and stressed the importance of choosing a right name and appropriate keywords (and monitoring them regularly after the app is released). He also gave us some advise on how to do marketing for your app, what works well and what you should not waste your time on.

Overall, going to the conference has turned out to be a great idea, not only because of the talks, but even more importantly because for me it was the first chance to meet some iOS developers from other companies in person. The organizers did a good job (apart from the last minute changes in the agenda), and I hope there will be a second edition next year. I'd also love to see more iOS- and Cocoa-related events and meetups in Krakow and in Poland in general.

Krakow Global Day of CodeRetreat

2011-12-14T14:41:00Z

THE BACKGROUND

Programmers savour the challenges coding brings. Endless strings of letters interlaced with numbers surely made a young computer wonk feel like the Matrix’s Morpheus more than once. This may lead to exponential ego overgrowth and grass starting to grow where one’s trodden.

Or, how it happens in most cases, the individual starts the never-ending quest for knowledge, usually crowned with ‘guru’ status among developers. Such was the case with Corey Haines, who came up with the idea of CodeRetreat workshops in 2009. As he put it:

"The idea was to develop a repeatable, day-long event that was focused on practicing the fundamentals of software development:"

Over the course of the events, a plan emerged: Corey (or other facilitator, as the organisers came to be known) heralded a CodeRetreat event, programmers gathered, the coordinators put them in a room and asked to code in random pairs on a given subject within a fixed set of rules and short time limit. After the last code lines had been written, programmers’ work was immediately wiped clean and they discussed what they have just created. The course of mingling-writing-deleting-discussing was dubbed a session.

The method proved to be so effective that other coders took heed and coderetreats mushroomed all over the world. Lunar Logic Polska decided to step in and sponsored Corey Haines’s flight and stay in April 2011 in Kraków to facilitate the first CodeRetreat here. People from Software Craftmanship Kraków took care of everything and the gallery from the Spring CR is available on their webpage.

After the event it was obvious that there is a need for such a gathering to take place more often, thus once more LLP funded and organised CodeRetreat, this time as a part of it's global dimension, dispatching Lunar’s own Andrzej, Konrad and Adam to prepare the workshops on 3rd December 2011. The CR event was so anticipated that the available "tickets” were given out in a matter of hours and about 40 people showed up.

THE EVENT

The 3rd fell on a Saturday and the first coders started flocking in at around 8 AM, snatching rockpool-blue CodeRetreat t-shirts sponsored by LLP and designed by our own Olga. The organisers greeted the participants at around 9 AM, briefly described the rules of CR and the problem they were to deal with - the Game of Life and wished them good luck.

Adam and Andrzej, along with Sebastian Bełczyk, the third facilitator, were hovering between the programmers always ready to give helpful advice, point out an overlooked problem or simply cheer up coders who came to a halt. Three 45-minute sessions passed, each focusing on different approach to the Game of Life: the 1st was just an introduction to the problem, during the second one facilitators suggested throwing the mouse away and at the third session programmers were urged to concentrate on the 4 rules of simple design. Each session ended with a coffee break, pair swap and a short discussion afterwards; the CodeRetreat morning concluded with a lunch from an Indian restaurant.

After the meal coders cooperated in another three sessions. The fourth was about testing - Adam, Andrzej and Sebastian encouraged people to "step up the testing ladder”, i.e. no tests - tests after - tests before - true tdd. After the fourth attempt to write the Game of Life there were two calls from other CodeRetreats: Łódź and New York. As for the fifth and five session, Adam described them shortly:

"In the fifth session we asked people to try programming either without loops or without conditionals. We also proposed the silent pairing exercise, which only a couple of people tried. In the last session we suggested "write the worst code you can" exercise."

After obliterating the last bits of code, the facilitators thanked the participants for a whole day of fun and invited them for a celebration which lasted up until midnight.

CONCLUSION

Global Day of CodeRetreat 2011 took place in more than 90 cities all over the globe. Hundreds of programmers met, churning out thousands lines of code and exchanging ideas, experience and different views on how programming should be done. LLP is proud to be a part of the GDCR 2011 success and hopes the event will be organised again next year. See you then!