Highlights of Monki Gras 2013

At the end of January I was lucky enough to be given a ticket to a two day long software development conference called “Monki Gras” (named after the company that runs the event, Red Monk) in London.

The theme of the conference was “scaling craft”, a pretty ambiguous theme which over the next two days was nicely pinned down by the wide variety of speakers. This theme was roughly translated into answering the question: “how do we maintain quality when scaling up to mass production?”.

Some of the speakers invited included, most importantly, Phil Gilbert of Design@IBM fame, who discussed how he is trying to bring a culture of design into the company, and to name a few more: Rafe Colburn from Etsy, Chris Aniszczyk from Twitter, Shanley Kane from Basho, Steven Citron-Pousty from Redhat and Ted Nyman from Github.

The conference was more than just good speakers. Fantastic food (specifically Japanese and Vietnamese) was provided on both days for lunch, along with some craft beers; coffee was available all day from an artisan coffee company, and the evening entertainment was hosted at London Fields Brewery where we were given a five course meal cooked by a top London based street kitchen. Quality was a theme in every aspect of the conference that mattered, whereas the hall where most of the talks were given was quite plain and basic, but all attention was on the speakers.

The first question that was addressed by the speakers was that of “What is craft?”. Rafe Colburn did a great job of opening the conference by discussing the common misconceptions associated with “hand crafted treasures compared to mass produced crap”. Not everything that is made at home is high quality, and not everything that is massed produced is is low quality. There are benefits to both – craft maximises the skill and creativity of the individual artisan and mass production optimizes predictability and repeatability.

Other speakers approached this topic too: Chris Thorpe has set up a company called The Flexiscale Company where he uses 3D-scanning technology to scan rare train engines so they can be forever preserved in their current state. Using these scans he is then able to 3D-print accurate models of the trains to any scale a model train enthusiast would desire. I personally have never seen the attraction to model trains, but his talk was one of the highlights of the conference as it honestly and unintentionally captured something really special about craft – the unashamed enthusiasm and passion for what you do. This same enthusiasm was displayed in the talk given by Diane Mueller (ActiveState) about a personal project to geotag Totem Poles in the Pacific Northwest (at the end of her talk she invited anyone interested to join her in tagging the totem pole in Virginia Waters). Manufacturers were given a good slogan for this mentality by Chris: “Make things people want, rather than make people want things”.

So how does a software company maintain this sense of passion, and craftsmanship, when it is scaled up to a company the size of IBM? Phil Gilbert’s talk was centred around design, but he touched on this idea when he asserted that developers can lose sight of the value, and ultimately the end result, when they only work on a small part of a huge product (and as part of a small team within Message Broker development I sympathise). His solution was something known as “Commander’s Intent”, the idea that in battle all soldiers are briefed on the overall goal of the mission before they are in the chaos of the battlefield. When they then enter the battlefield no further orders are given; it is the responsibility of the commander to ensure that everyone has understood their goal and how to reach it so they are able to make informed decisions themselves rather than have minute details dictated at every move.

To apply this to software development Phil suggests appointing someone to own the decision making process, and a trusted community of people reviewing (but not dictating) outcomes. But most of all, ensure that your staff prepare for (great) outcomes and understand the value of what they are working on. Cyndi Mitchell from ThoughtWorks expanded on this, adding an analogy from her experiences growing up on a hog farm (where the product is the hogs and the developers are the farmers), in particular she stated that “everyone in the system has to understand quality”.

In the most extreme example of this, Ted Nyman from Github discussed how their organisation has no managers. In response to this every employee must have a sense of ownership, and if this is effective everything the employee needs to get done will get done.

Although the conference was a technical one, it became clear that software development was only the medium in which people were discussing their ideas. Instead the conference was really about culture, and on this topic there was a lot of food for thought. In Heroku, a platform as a service company, the number of deploys a day are in the high hundreds. “Move fast and break [stuff]” was the (family friendly version of the) mantra for their organisation, and this was only possible if developers’ time became sacred. They introduced the headphone rule: headphones on means ‘do not disturb’, and the fantastic piece of advice “work in caves, dwell in commons”. This demonstrates the flip side to protecting developers time: when you’re not working, communicate! Coffee breaks become an important part of the working life (hence the title of their presentation “Coffee as collaboration”) as this is when ideas can be shared and discussed. Taking time to document your work to get the recognition you deserve and killing off projects that aren’t working can only happen if communication is just as important as the development.

This protection of the developer was also discussed by Rafe Colburn, whose advice for companies looking to scale was to automate everything that could be automated, leaving time for developers to work on their beloved craft. Phil Gilbert suggests using release hills with clear goals (three maximum) so that people can reclaim their craft, but also building in regular iterations of design and innovation to keep the craft fresh.

On the topic of iterations, Government Digital Services (GDS) discussed how in the space of two years they scaled their team from a handful of people to 200 employees. They attributed their success to constant iterations of processes, tools and people, avoiding the dreaded “single point of failure”. Understanding how to effectively do this comes down to understanding your “ecosystem” (a term commonly misused), as explained by Steven Citron-Pousty. He used his background in ecology to encourage people to think about nature’s ecosystems in comparison to those in their organisation, in particular identify the keystone developers as well as the day-to-day developers, and understand the sometimes unexpected relationships between them and their colleagues.

Another point of discussion (initially introduced by Mazz Mosely from GDS) was the issue of “rock star” developers. These can be the aforementioned “single point of failures”, but more importantly they are those mysterious developers that the entire success of the product is pinned onto. Other than not being what they may be hyped up to be, rock stars can also be disruptive to teams – feeling that only their opinions count and not using the shared knowledge of their colleagues. A better approach is to cultivate an environment where everyone is respectful and understands that the “users” of your product are not just the end-users, but also your colleagues.

In summary (some takeaway coffee if you will), culture is one of the most important aspects of a company. Culture, as asserted by Shanley Kane and Ted Nyman, is not the furniture in your office or the perks your company offers, but it is what eventually picks between two good ideas. With this in mind, it becomes increasingly important that the whole organisation has the same mentality behind their work. As software engineers we like to think of ourselves as craftspeople, and can easily become frustrated if our work becomes mindless, so how can we avoid this happening? Here are some top tips to avoid this kind of disappointment:

  • Teams should be honest about what they can achieve in an iteration, at the risk of losing faith in the product and only completing the easy tasks just to tick them off a list,
  • expect, encourage and respect feedback from your colleagues
  • and understand the quality and value of what they are working on.

Monkigras 2013: Scaling craft

The work of William Morris, my GCSE history teacher said, was a bit of a moral dilemma. Morris was a British designer born during the Industrial Revolution. British (and then world) industry was moving rapidly towards mass production by replacing traditional, cottage-industry production processes with the more efficient, and therefore profitable, machines. One thing that suffered under this move to mass production was the focus on function and quantity over decoration and quality. Morris reacted against this by designing and producing decorations like wallpaper and textiles using the traditional craft techniques of skilled craftspeople. My history teacher’s point was that although Morris, a passionate socialist, was able to create high quality goods by using smaller-scale production methods, only wealthy people could afford to buy his designs; which was hardly equality in action. On the other hand, the skills of craftspeople were being retained, quality goods were being produced, and the craftspeople were getting paid for that quality of their work.

My pretty, handcrafted latte
My pretty, handcrafted latte

Monkigras 2013, in London last week, took on this theme of ‘scaling craft’ in the context of beer, coffee, and software. All parts of this trinity of software development can benefit hugely from a focus on quality over quantity. Before I went to Monkigras, I wasn’t really sure what to expect from a tech event advertised as having a lot of beer. It did have a lot of beer (and coffee) available but if you didn’t want it you could avoid it (several people I talked to said they didn’t usually drink beer). And no one seemed to get ridiculously drunk. And there were a lot of very cool talks.

The beer was also a fun analogy to apply to software development. Despite pubs in the UK closing hand over fist at the moment, microbreweries are on the rise. Microbrewing is about producing beer in small quantities on a commercial basis so that quality can be maintained whilst still viable as a business. One of the things we learnt from a brewer at Monkigras is that the taste of water varies according to where it comes from. Water is a major component of beer so if the taste of your water supply changes, the taste of your beer changes. To maintain the quality of the beer you brew, you must work within the natural resources available to you and not over-expand. Similarly, quality comes from skilled and knowledgeable people who need to be paid for their skill. If you take on cheaper staff and train them less so that you can make more profit, you will end up with a poorer quality product. You get the idea.

Handcrafting a wooden spoon.
Handcrafting a wooden spoon.

This principle applies to all areas of craft, whether it’s producing quality coffee, a quality wooden spoon, quality conference food, or organising a quality conference, you have to focus on quality and ensure that if you scale what you do so that it’s more readily available to more people, you don’t sacrifice quality at the same time. And, importantly, that you know when to stop. Bigger doesn’t necessarily mean better.

Software is misleadingly easy to produce. Unlike making physical objects, there is very little initial cost to producing software; you can make copies and then distribute them to customers over the Internet at very little cost. Initially, at least, it’s all in the skill of the craftspeople and their ability to identify their target users and market. If they can’t make what people will buy, they will go out of business very quickly. As software development companies get larger, the people who make the software inside the company become further removed from the selling of their software to their customers. So they become more focused on what they are close to, the technology but not who will use it.

Phil Gilbert on IBM Design Thinking
Phil Gilbert on IBM Design Thinking

Phil Gilbert, IBM’s new General Manager of Design, comes from a 30-year career in startups, most recently Lombardi, where design was core to their culture. IBM has a portfolio of 3000 software products so, when Lombardi was acquired by IBM, Phil set about simplifying the IBM Business Process Management portfolio of products, reducing 21 different products to just four and kicking off a cultural change to bring design and thinking about users to the centre of product development. Whilst praising IBM’s history of design and a recent server product design award, he also acknowledged at Monkigras: “We are rethinking everything at IBM. Our portfolio is a mess today and we need to get better”. Changing a culture like IBM’s isn’t easy but I’ve seen and experienced a big difference already. Phil’s challenge is to scale the high-quality user-focused design values of a startup to a century-old global corporation.

One of the things that struck me most at Monkigras, and appealed to me most as a social scientist, was the focus on the human side. Despite it being a developer conference, I remember seeing only one slide that contained code. The overriding theme was about people and culture, not technology; how to maintain quality by maintaining a culture that respects its craftspeople and how to retain both even if the organisation gets bigger, even if that naturally limits how much the organisation can grow. Personal analogy was also a big thing…

Laser-scanned model of the engine
Laser-scanned model of the engine

Cyndi Mitchell from Logspace talked about her family’s hog farm and working within the available resources. Shanley Kane from Basho used Dante’s spheres to describe best product management practices. Steve Citron-Pousty from RedHat use his background as an ecologist to manage communities and ‘developer ecosystems’ (don’t just call it an ecosystem; treat it like one). Diane Mueller from ActiveState talked about her 20%-time project to build a crowdsourced database of totem poles and the challenges of understanding what gets people to want to contribute to such projects. Elco Jacobs talked about his BrewPi project: automatically managing the temperature of his homebrewing fridge using a RaspberryPi based controller, and how he has open-sourced to build a community to kick start it as a potential small business. Rafe Colburn from Etsy more directly makes the link between craft and software engineering in his slides.

3D printer making a spoon
3D printer making a spoon

I don’t know much about William Morris so I don’t know which presentations he would have enjoyed or disagreed with. Morris was a preservationist and started the Society for the Protection of Ancient Buildings to ensure that old buildings get repaired and not restored to an arbitrary point in the past. So maybe he would have found laser-scanning and 3D printing interesting. Chris Thorpe is a model train geek and likes to hand-make his own models of real-life objects. He too is interested in alternatives to mass manufacturing and has started to look at how to make model kits. He uses a laser to scan the objects and a 3D printer to prototype the models. He can then send the model to a commercial company who can make it into kits for him to sell. He has recently used his laser-scanning technique to scan a rediscovered old Welsh railway engine to preserve it, virtually at least, in the state in which it was found.

I had a great time with lots of cool and fun people. Well done to @monkchips for scaling a conference to just the right level of intimacy and buzz. The last thing I saw before I left was the craftsman making a wooden spoon pitted in competition against the 3D printer making a plastic spoon.

You can find many of the slide presentations and more about the conference Lanyrd.

The post Monkigras 2013: Scaling craft appeared first on LauraCowen.co.uk.

MQTT Joggler

Spurred on by the success of getting Mosquitto working on a Raspberry Pi, I recently had a play with MQTT on the Joggler. The O2 Joggler is still a great device for hacking and I currently have SqeezePlay OS running on it.

The reason I wanted to try and get MQTT on the Joggler was to make use of its light sensor, and publish light levels over MQTT. It all turned out to be pretty simple since most of the work has already been done by other people!

First thing to do was read the light sensor and get that working with an MQTT client. I had to skip some of Andy’s instructions and just built the client code rather than attempting to get doxygen working. Once I’d mashed up the light sensor code and publish example I could compile the worlds most pointless MQTT publisher:

gcc -Wall publightsensor.c -L../bin/linux_ia32 -I../src -lmqttv3c -lpthread -o publightsensor

Next it was time to check the results. This too was quick and easy thanks to the MQTT sandbox server, which has a handy HTTP bridge. And the final result... was a completely unscientific and slightly dingy light level 4! Now I'll be able to turn on a lamp using an unreliable RF controlled socket and see whether it worked or not!

Update: the code really is all in the existing examples but I've created a Github Gist in case it's any help: mqttjogglermashup.c (11 February 2013)