Tag Archives: monkigras

The Monki Gras London 2013: scaling craft, how to be happy at work, defining software excellence, and lots of beer

I attend numerous technical events, most of which are vendor-specific. There is nothing wrong with vendor-specific events. If you want to explore what is on offer from that vendor and quiz  their people, they are ideal. You will be aware though that they are promotional events and give you a skewed view of the world, for which you need to make allowance.

Therefore I particularly value events which are not vendor-specific. They may still offer a skewed view of the world, but at least it is vendor-neutral. Redmonk’s Monki Gras is one such, managed by analyst company RedMonk, in particular by its co-founder James Governor.

image

The event is small, with around 200 attendees, with a bias towards software developers. Seeing the picture above you will observe that it is not entirely vendor-neutral, in that it is sponsored by companies including Amazon, Adobe, twilio, Red Hat, Citrix, SAP and Heroku. Multi-vendor then, rather than vendor-neutral? Arguable, but there was little patience for product pitches and the event was one which was able to hear Basho’s Shanley Kane telling us to discard all our tools (a move unlikely to please vendors), so on a scale where zero is pure marketing fluff and ten searing honesty, I would award it at least an eight.

The Monki Gras is not just about technology. It is also about craft beer. This its second year, and there was even more beer content this time around. Possibly (said sotto voce) more than you might prefer if you have only a passing interest in the subject; but if so, perhaps this was not the right event for you.

image

Why the beer? Because developers like it. Because it is a craft that does not scale easily. Because it is characterful, flavoursome and distinctive, and individual examples aspire to excellence, all qualities that I suspect Redmonk value.

The combination of Redmonk values, generous sponsors and small size make this an event with exceptional catering. Not only craft beer, but also fresh fruit, Sushi, fresh ground coffee prepared by a skilled barista, and at the evening event, a breathtakingly good selection of cheeses of which I got to taste only a few slivers because my hotel arrangements required an early departure.

image

One of the ironies of the Monki Gras is that this kind of excellence does not scale well, with long queues for coffee and lunch, and on the Thursday evening one of the slowest meals I have attended. I left after three hours by which time it had reached the third course, but missed dessert and cheese. Good things take time and I guess this is all part of the Monki Gras experience.

What about the technical content? Technical may be the wrong word; and the published agenda is only an approximate guide. A Twitter search is one way to discover what was said; or you can check my tweets for those days; despite poor wifi there were enough smart gadgets that plenty of tweets got through. The focus was on the human aspect of software development, summed up for me by Cyndi Mitchell of Logspace and Thoughtworks, who said:

Software is fundamentally a human, interactive activity – if you don’t understand that, forget it.

Here are some other highlights, not comprehensive, but some of the things which caught my attention.

Rafe Colburn from Etsy who observed that to improve the craft of software development, you need to make time available by automating whatever you can.

Craig Kersteins and Matt Thompson from Heroku talked about developer productivity, with the startling statistic (I have no idea how they get these figures) that 76% of the worst-performing engineers suffer frequent interruptions. Software development needs focus; they suggested 4 hours of continuous uninterrupted work each day. At Heroku they use headphones as a “do not disturb” sign and respect that.

That risks the opposite danger, lack of communication. Hence another Heroku strategy is to give staff free lunch with long tables, to promote communication, and slow coffee machines that make a jug at a time, to promote sharing and collaboration.

Mazz Mosley and Nick Stenning from the Government Digital Service – which is transforming UK government IT from the inside, with generous use of open source and common sense – spoke on not recruiting developer rock stars, who create a single point of failure in your team. Rather, they aim to nurture collective intelligence.

This talk went down well at the Monki Gras, but while the thought makes sense, it intrigues me. Could the same person who becomes a “rock star” in one team be part of “collective intelligence” in another? Is not this more about how you manage your team, than how you recruit? And could a key leader that creates such a team be a bit of a rock star for doing so?

Phil Gilbert from IBM spoke about transforming IBM’s software products with design and rationalisation. The slide that has stayed with me showed how 20+ products in the areas of business process management were consolidated into two or three.

Chris Thorpe from Boffin talked about steam engines and 3D printing. Using 3D printing, steam engines can be repaired, while in another context model railway enthusiasts can get models in whatever size they want.

Steve Citron-Pousty from Red Hat gave us a sideways look at technology by talking about ecosystems. How do you nurture a vibrant ecosystem as opposed to one in which just a few creatures dominate? The answer is about monitoring, measuring, and testing hypotheses.

Ted Nyman at GitHub gave a memorable talk on being happy at work. His answer: no managers.

image

He described how GitHub is managed: nobody reports to anyone else, decisions are made by consensus, teams form naturally, nobody is forced to do anything, but individuals are highly motivated because they have authenticity and autonomy. Employees are happy and nobody ever quits. “Developers are awkward people, accept awkwardness,” he added.

This was another thought-provoking talk. How much of GitHub’s management model would translate or scale to other businesses? Does it depend on having smart, highly motivated team members? Will it work for ever, or end in disaster? Is Nyman’s description accurate, or are there disguised channels of authority which he did not articulate?

Day two, Friday, opened strongly. I have already mentioned Shanley Kane’s talk. She addressed the problem of dishonesty in software development, explaining that software roadmaps which show features on a timeline are inherently dishonest and cause erosion of trust. Developers have a responsibility to explain to others in the business that development does not work like that. Her suggested alternative is some sort of interactive document covering “what we’re working on”.

Cyndi Mitchell, also mentioned above, talked about excellence in software development. This is not just about technically sound code, but is multi-faceted, including business value, customer value, user experience, delivery and operations as well. It was another take on a common theme in Agile: the team is everyone, not just the developers.

Chris Aniszczyk from Twitter spoke about open source software. Twitter always evaluates open source options before risking wheel reinvention by cutting new code. He also advocates always writing code on the assumption that it will one day be open source. This promotes high quality APIs, sensible naming conventions, and other good things. Twitter aims to give code that is not its “secret sauce” back to the community, he said. However, Twitter avoids code with viral open source licenses like the GPL; it causes too many problems, he said.

An intriguing aside; Aniszczyk says that Twitter acquires companies to get the people, since “you can’t hire engineers these days.” This may create an open source project, as the code that company was working on is given away/abandoned to the community. I am not sure what examples of this process there are.

After that, there was lunch, more beer, brewers spoke, and a wood carver competed with a 3D printer to make a spoon; I’ve written about this here.

Lee Bofkin from Global Street Art spoke about street art. Where we see a wall or an alley, he said, a street artist sees a place that can be transformed with art. His slides were wonderful; check the Global Street Art site for a flavour.

image

There is no event quite like the Monki Gras; it was not deeply technical but was rich in ideas. Plenty to reflect on.

Two ways to make a spoon: 3D printing in action

Last week I attended the Monki Gras, a distinctive event exploring how to scale craft, mainly in the context of technology but also in the context of beer.

On the second day there was a light-hearted competition. Who can make a spoon faster, a wood carver, or a geek with a 3D printer?

image

A skilled craftsperson can make a spoon in around half an hour, we learned.

In the other corner was a techie, a laptop computer and a 3D printer.

image

image

Said techie (I did not get the name unfortunately) had downloaded a spoon design from the internet and was printing it on a Prusa Mendal RepRap machine. Cost: from a few hundred pounds if you self-assemble, or £1000 or more if you purchase complete.

The software is open source: slic3r to convert a 3D model into printing instructions, and pronterface to talk to the 3D printer.

Looking in more detail at the printer, what you have is a system of cogs, rails and stepper motors that lets a print head move in three dimensions. The raw material is a spool of green plastic from faberdashery. This could be fed from the rotating white spooler at the top of the machine, though in this case only a little was needed and it was floating loose.

image

The plastic is melted by the print head and squirted out to form the object being printed. Apparently once formed it is reasonably rigid and strong.

image

Attendees observed that the competition was pretty silly, since speed is not a goal of 3D printing (and the wood carver was indeed the victor). In that sense, 3D printing is a poor way of scaling craft, though it has some potential in that a brilliant design can be reproduced as an object many times over. If you want a lot though, it is worth investing in traditional plastic moulding: setup is expensive, but once you have done one, you can do thousands more cheaply.

Still, imagine what 3D printing enables. I have a nice set of headphones, for example, which are useless because a small plastic component has broken. If I can get hold of (or make) a 3D computer model of the part, I can now make that part for little cost. You do not even need your own 3D printer; services like Shapeways let you upload the design and get the part in the post a few days later.

In niche areas like model trains and landscapes, 3D printing makes models viable even if only a few are needed. You can also have exactly the size you want, rather than being restricted to the standard sizes that are volume manufactured.

For inventors, 3D printing makes prototyping easier. You can iterate through hundreds of slightly different designs and try them out physically, rather than relying on computer models.

The opportunities are fantastic, and you can get started for little cost; though the guy at Monki Gras did note that his RepRap was temperamental and therefore a high maintenance gadget. Maybe by making a few modified parts he can improve it.

Telcos have a dying business model – APIs and cloud services are the future says Alcatel-Lucent’s Laura Merling

Laura Merling from Alcatel-Lucent spoke at the Monki Gras conference in London earlier this week, saying in effect that telecommunication companies have a dying business model.

She gave a two-minute summary of Telco history.  “First it was all about voice,” she said. “Then the intertubes happened. Now you had data … then it went back to voice, the big push for wireless. Then of course wireless moved, so it’s not about voice any more, it’s about the data.”

She expects the next step to be “connected devices … the phone goes away, everything you do both data and voice happens on other devices.”

What does this mean for telcos? They have become commoditised, she said, suppliers of data plans. “It is a big commoditised business that has no real innovation.”

“In the future, the data plans dies,”, Merling says. “Think about it. How many devices have you got? Think about connecting all of those. You probably want the same data plan. But why pay for a data plan? How will telcos make money? You can’t just keep increasing the data plan.”

Instead, the money is going to come from the APIs and accessing the services.

Enter Twilio, a virtual telco. “I think of twilio as a craft telco”, said Merling, tying in with the beer theme that flowed through Monki Gras. “Do they sell hardware? No. They have software and APIs.” She says the Twilio business model scares the industry: it is based on transactions, not data plans. She also noted how old established vendors are buying up software-based providers, such as BT acquiring Ribbit and Microsoft acquiring Skype.

Tomorrow’s telco, says Merling, is a based on a software stack. “Antennas and towers are not going to go away, but the infrastructure becomes all software based … combining network services with cloud infrastructure.

“At Alcatel-Lucent we sell hardware. We sell big giant boxes. But this is where it is going.” She says the telcos are now aware of this, hence the title of her session “How telcos got API religion.”

Her final prediction? “Jeff Lawson becomes the CEO of AT&T. Why? Because the model has to change.”

It was a thought-provoking talk, though the unspoken question was whether in fact the telcos will successfully transition or whether they will simply become less important, continuing to maintain the pipes while others profit from what flows through them.

I interviewed Twilio CEO Jeff Lawson in October last year.

A quiet revolution in UK government IT: open source ousting big-vendor lock-in

The most striking and surprising presentation at the Monki Gras developer event in London earlier this week was from two quietly spoken men from the UK government’s Cabinet Office. James Stewart and Matt Wall work on the Government Data Service (GDS), and what they are doing is revolutionary.

What is the GDS? “It’s a new branch of the cabinet office which exists to deliver public services, public sector information in-house, rather than the traditional out-sourcing model,” they explained, though it turned out to be rather more than that.

Wall described his experience of talking to government workers about their IT needs.

A common thing you see from very small to very large is someone in government who wants to get something done, who has a business problem or a user need that they want to serve, surrounded by a complex array of integrators, vendors, contractors, suppliers, and all of that, kind-of locked into that, their ability to manoeuvre or deliver services [is limited].

he explained. The only solution is to reform the way software is procured. They described their boss Mike Bracken’s goal:

We want to move from government procuring systems to government commissioning them, whether we build them ourselves, or just that we know what it is we’re asking for. We need that knowledge.

This is also about breaking the hold of the large vendors and finding ways to work on a smaller scale.

If you want to buy something in government, traditionally, some software or some system, the amount of momentum that you have to get up, the amount of people you can easily engage with, they tend to be from companies that are absolutely vast and they tend to take projects that are absolutely vast, the whole mechanism of working is stultifying for everyone involved. It is not just us, a small group of developers sitting in an office able to write some stuff, because that’s not scalable, you can’t do that for everyone. It’s finding small to medium sized companies, partners, out there in the market and finding ways to engage them … why should five very large companies get all the work?

Mike Bracken and the Cabinet Office minister Frances Maude are currently on the West Coast of the USA, they said.

They were invited to meet the usual suspects, Oracle, the major systems integrators. They cancelled it. They’re visiting Joyent, they’re visiting 10Gen, they’re visiting Twilio [applause]. It’s a wholesale change. We’re looking at how great web services are built.

There is also a commitment to open source. “All of the code that we’re producing is open source and out on the Internet,” they said.

What tools do they use?

Most of the core apps are in Ruby, with a mixture of Sinatra and Rails, and some Scala. We’re using a mixture of MySQL and Mongo for the database,

they told us.

The GDS is currently only about 30 people, 10 of whom are developers. How much impact can such a small team have?

We’ve just started and we’re very small. We’re already having a significant impact in some quite large and some quite small projects. The incoming demand that we face across central government and local government is absolutely astronomical, and one of the things that’s important to resolve over the coming years is how to manage that demand and provide services, abilities and communities for people . . . we never want to parachute into somewhere, rewrite all the systems and then go off somewhere else., that’s not sustainable.

Can this small group really change government IT so profoundly? That is an open question, and perhaps in the long term they will fail. There is no doubting though that this particular team is doing inspiring work. This blog post from GDS yesterday describes how open source participation was used to fix a government web site; it may seem a small thing, but as a new and different approach it is significant.

For more information see Mike Bracken’s post This is why we are here, and take a look at the team’s early work on GOV.UK, which is in beta.

image