while it’s compiling

While It’s Compiling: Skills Matter interviews Tom Stuart

In the run-up to CukeUp! 2015, we caught up with BDD expert and enthusiast Tom Stuart to ask him about his talk and what he thinks of the current state of BDD. Tom is a computer scientist and programmer. He has lectured on optimising compilers at the University of Cambridge, co-organises the Ruby Manor conference, and is a member of the London Ruby User Group. You can find him on Twitter here, and visit his website here.

You’re leading an open-discussion at CukeUp that’s looking to define what BDD actually is. Can you give us a brief overview?

The title of the discussion is “WTF is BDD?”, and the idea is to try to get everyone to agree on a simple, clear, concrete description of what BDD is and literally how to do it. I don’t know if that’s a realistic goal, but I thought it would be interesting to try.

Where did this need to redefine BDD come from – what has led you to this talk?

It’s not about redefining it so much as just nailing down a usable definition in the first place. I honestly don’t think we have one right now and I find that frustrating.

The term “behaviour-driven development” has mostly worked well for discussions between experts — primarily this means consultants and trainers — because the people involved in those conversations know how things have been done differently (and badly) in the past, and are able to use that experience to interpret, frame and prioritise the whole cloud of ideas that swirls around BDD.

But I’d say there’s been a failure to communicate the essential idea of behaviour-driven development to the wider non-expert community, which is a shame because it’s the non-experts who stand to benefit the most from it. I find BDD very useful but I also find it difficult to persuade other people to do it because there’s nothing to point at to show them what I’m talking about. That makes it look like it’s not a real thing. It‘s embarrassing.

Right now the only guaranteed way to “learn BDD” is to pay one of those consultants or trainers to come and teach it to you, which is fine in itself, but it shouldn’t be the only option. If BDD has validity and value then we should be able to communicate it straightforwardly, without jargon or enterprise-consultant-speak.

And even among experts there’s a lot of noisy disagreement over the details of what BDD is. There are so many blog posts out there about “doing BDD right”, “doing BDD wrong”, “BDD is not X”, “BDD is just Y”, “if you’re not doing Z you’re not doing BDD”, and so on. This sort of debate is a sign of a healthy and inquisitive expert community, but again it’s not helpful for getting people engaged in the basic principles and practices of BDD. It puts them off — “if these clever experts can’t even agree on what it is, what hope do I have?”. I like to think that if we set aside the fine-grained disagreements for a moment, we’ll be able to agree on some big fundamental stuff that would be useful right now to people who need help with their software development process.

You’re currently working on a book and screencast – How to Write a Web Application in Ruby. How did that come about? And when can we expect to see it!?

It’s adapted from a workshop I run for Ruby developers. In the workshop we incrementally build up a complete web application from scratch by reading the appropriate specifications and using only the Ruby standard library — TCPSocket, URI, CGI, that sort of thing. Then, once it’s working, we refactor it by replacing bits of our hand-rolled implementation with battled-tested third-party code like Rack, Active Record and Action Pack. So halfway through the workshop we have a long manual implementation of a web application, and by the end we have essentially a short single-file Rails app. People seem to get a lot out of the workshop when I run it, so the book and screencast are about taking that same content and making it available to anyone online.

The stated goal of the book is to help Rails developers to understand their tools better by illustrating what each piece does in isolation and how they fit together. Its unspoken ideological goal is to make the point that software isn’t magic and it doesn’t come about by a process of divine revelation. It’s just stuff made by people, and you’re a person, so you can make that stuff too. You don’t need to wait for someone else to come along and make a framework for you to use; you are capable of building a thing yourself. Of course there are good pragmatic reasons to reuse someone else’s work instead of building everything yourself, but ideologically it’s important to know that you have a choice. Software is brilliant and it should be empowering, not constraining.

I’m ashamed to say that it’s become a bit of a long-term project now, not because I’m not excited about it, but just because I’m a terrible procrastinator and I don’t have a publisher breathing down my neck about it, so I can easily put it on the shelf for months at a time while I’m working on other things. I first announced it on the Ruby Rogues podcast in August 2013 so it’s definitely been brewing for a while.

I’ve resolved to get it shipped this year. That sounds terribly pessimistic. What I mean is that I’ve made a resolution to speak at fewer conferences in 2015, because they ordinarily take up so much of my time, and the idea is that I’ll be freed up to get the book finished. It’s the main thing I’m working on right now. I just checked the PDF and it’s 77 pages so far. So it is real and it will be out before too long.

Your writing spans a pretty huge range of topics – not just technical (like this post from your website on the London Cycle Hire scheme). Where do you find your inspiration from?

I would love to say something motivational and high-minded here, but the truth is that my writing is mostly born of frustration. I am very excited about the possibilities presented by general-purpose computation, and that excitement turns to frustration when those possibilities go unrealised because of bad education or lazy design or whatever it is.

So much of what is wonderful and beautiful about the computable world is hidden under a thick layer of inane jargon, poor documentation, crummy explanations, arrogant behaviour, confusing interfaces and so on, and I feel compelled to try to dismantle those things whenever I see them. Often that amounts to just unproductive complaining, but sometimes it motivates me to try to build a really clear explanation of a particular idea, or at least a really clear illustration of why some existing thing is bad. That’s actually still just complaining but I invest some effort in dressing it up as something superficially more constructive.

Explaining things clearly, whether through human language or computer code or interaction design, is really difficult to do, but that’s what makes it important and worthwhile. I think that you can change someone’s life in a tiny way if you help them to understand something fundamental about the universe, so it’s worth putting a bit of effort into. In practice the main thing I’ve learned is that this is a terrible way to try to make a living.

Were you always going to be a developer? What do you think you’d be doing if you weren’t?

I was fortunate enough to have access to easily-programmable computers from a very young age, so yes, I’ve been programming for as long as I can remember, and it’s hard to imagine doing anything else for a living. I suppose that latterly I’ve been spending more time explaining things to humans than to computers, so under different circumstances maybe I’d have become a teacher. I am a huge fan of mathematics so it’s likely I’d have ended up as a maths teacher, if not an actual mathematician, if computers hadn’t existed. It’s a frightening thought.

Finally, and back to CukeUp; what are you looking forward to most at this years conference?

Well, obviously my bit is probably going to be amazing, but social convention dictates that I pick something else. Actually I’m really looking forward to the workshops, because workshops (more so than talks) are often an opportunity to really learn something new — to be that person who’s having their life changed in a tiny way. So I’m hoping to be shown different ways of thinking about Cucumber and BDD, and to get the chance to ask some awkward questions, and to find something new and interesting to complain about.

While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.

While It’s Compiling: Skills Matter interviews Martin Odersky


On the day the Scala eXchange welcomes more than 500 speakers and delegates to the Business Design Centre, Skills Matter catches up with keynote speaker Martin Odersky. The German computer scientist is the creator of Scala and the founder of Typesafe, a company to support and promote Scala. Currently a professor of programming methods at EPFL – the Swiss Federal Institute of Technology – in Lausanne, Switzerland, Martin Odersky told us about keeping Scala lean, which industries love Scala the most, and whether Scala can remain the essence of what Typesafe is and does.


Scala was first born in 2003. Has there been a lot of pressure to keep adding features? And have you always been convinced about the need to keep it lean?

There’s always pressure to add features. Users always want new features. So we tried for a long time to keep the feature set down to a reasonable size and…hopefully we’ll be able to make it even smaller.

You have described Scala as a fusion. Can you explain this in a little more detail?

The idea underlying Scala is that object-oriented programming and functional programming are not opposites but two sides of the same coin, and that one gains a lot by merging them. That’s not an amalgamation, taking all these features from functional programming and adding all these features from object-oriented programming – that way you would get a fairly large language. It’s really a fusion…So for example, the functions in Scala themselves are actually objects. Functions and objects are, in Scala, very much the same thing. And the same holds (true) for a lot of other things. Unlike many other languages that have classes and functions as types separately and then algebraic data types separately, we have one concept which is essentially classes forming a hierarchy. They serve as a framework for doing pattern matching as well, which in other languages requires an algebraic data type. So in that sense, Scala tries to have only a few concepts but very generally composable ones.

Are there particular organisations or industry sectors in which Scala has proven particularly successful?

We’ve got quite a few. I think its used everywhere there’s a JVM and nowadays it’s starting to be used on the client with Javascript as well. But there are a few verticals where Scala particularly common: It’s very much established by now in Big Data and machine learning. There, Scala is probably the number two language behind Python. Another big vertical is e-commerce – think of Walmart Canada, and many others. Another one is the finance industry – the most prevalent in London – so in the banks and the hedge funds Scala is also very common.

What have the main criticisms of Scala been and how have they been remedied?

Some of the difficulties comes from the user community, because now you have Java programmers and Haskell programmers that form part of the same community and that has proven to be a much tougher challenge than the technology. Sometimes these communities don’t get along very well, sometimes its very hard to read somebody else’s Scala code because there are different ways to write the same thing. We try to help by establishing simplicity as a criterion for a middle ground.

What was your vision when you set up Typesafe and have you been surprised by its success?

Scala already was a success and we had just run the first Scala Days..there was a lot of excitement and also a lot of people from industry – a lot of companies like LinkedIn, people from Swiss banks, Foursquare etc were talking about it. And that’s when it dawned on us that it really had bypassed the capabilities of just a research lab at my university. It was becoming too much work to continue to support it and also, we could see the opportunity. So we joined with the Akka team in 2011 to form Typesafe, and Typesafe now is I think still very much true to these roots…but it has also developed the reactive space starting with Akka, with middleware that is more application oriented and less language oriented.

A question about the direction Typesafe is going and its ongoing support of Scala, given its development of other products such as Akka and Play for Java developers. Will Scala always remain at the core of Typesafe?

Yes, I do think so. Scala is very much the essence of what Typesafe is. Internally everybody does Scala and everybody loves the Scala APIs. That’s not to say we don’t also do Java and Java 8 for the bigger market – that’s very sensible and we have to do that. But at its roots, it’s a Scala company and it will stay one.

You were a student of Niklaus Wirth in Zurich. How did that experience influence you?

When I was young, I was sort of a compiler hacker…and Modula 2 was a new language at the time and for me a very exciting language, so I wrote a Modula 2 compiler. I was actually on the cusp of joining Borland, at the time the big programming language and software company, but I decided to wait and finish my masters thesis. And then I realised that I had fun doing research so that’s when I decided not to go to Borland but to go to Niklaus Wirth – the inventor of Modula 2. At the end of my studies in Zurich (with Niklaus Wirth), I decided that functional programming was really cool and that I wanted to do more, so that’s why after Zurich I ended up doing much more functional programming.

You have had a long, varied and impressive career. What has your motivation and objective been throughout?

In Zurich with Niklaus Wirth (I was working with) very practical languages, which were also quite efficient, which functional programming wasn’t at the time. Towards the end of my PhD I discovered that functional programming could be very elegant and theoretically well founded, and that appealed to my sense of elegance and rigour. After that, I always wanted to bring the two together – to do something that’s really practical but that has the elegance and rigour of functional programming. So that led me to the work to combine functional and object oriented programming, first with Pizza, then with GJ, afterwards with Funnel and Scala.   The central question was always whether we can take the proven mainstream – object oriented programming – and the more academic notion of functional programming and combine the two harmoniously, keeping the good parts of both? That has driven me for most of my professional career.

While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.


While It’s Compiling: Skills Matter interviews Cate Huston

While It’s Compiling is a series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.


Cate escaped from graduate school to be a Software Engineer at Google, where she’s focused on a variety of mobile experiences over the last 3 years including GMail, Google Docs, Maps and now Ads. She used to be an international hobo, teaching programming in the US and in Shanghai, training in martial arts in China, qualifying as a ski instructor in Canada, and aimlessly wandering around Europe.

After nearly 7 years as an expat, she’s now readjusting to life in London.

You can find her on Twitter and on her blog, Accidentally in Code.

Cate will be giving a talk about building for mobile devices at iOScon, our first ever iOS conference. Check Skills Matter for updates and tickets!

1. What drew you towards mobile platforms?

It wasn’t a deliberate career choice, I interned working on a J2ME mobile app and when I went to work for Google I ended up focusing on mobile products. Really, I just like to build things for humans, so working on mobile is great because people love their mobile phones.

2. Is there anything in particular about iOS that appeals to you?

I carry both an iPhone (5) and a an Android (Nexus 5), and use them about equally. I slightly prefer my iPhone, mostly because the UX on some of the apps I use a lot (like Twitter!) is better. And the camera is great, I take all my pictures on my iPhone.

3. What new projects are you working on right now?

At work, I’m thinking about some of the wider implications of mobile that go beyond just the experience we build – for example, when people are making decisions the research phase is heavily mobile.

In my “free” (ha) time, I’m working on a book chapter for the Architecture of Open Source 500 lines or less project. It’s about image manipulation.

4. Where do you see iOS in the next five years?

Wearables. I have a Misfit Wearable, a Jawbone UP and a Nike Fuelband. They have their flaws, but I love the idea of being able to better track what I’m doing and optimize it. I was really sad to see Nike cutting back on the hardware to focus on software, but the rumor about Apple wearables gives me hope!

5. What do you wish you’d known when you’d first started out?

Things I still wish I knew – about how the hardware, and lower levels of the networking stack, GPS chips etc work.

6. If you could ask the iOS community anything, what would it be?

I’ve been thinking a lot about decision fatigue – the original example of this is the jam experiment: when people were offered a bigger selection of jam in a grocery store, they were more likely to taste and less likely to buy.

I’d love to know what effect people think decision fatigue has, or should have, on mobile design?

Got a comment for Cate? Leave it below!

While It’s Compiling: Skills Matter interviews Udi Dahan


While It’s Compiling is a series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

We managed to catch up with Udi Dahan this week, who talked to us about NSBCon 2014, microservices and the benefits of NServiceBus for smaller enterprise systems. Udi is the creator of NServiceBus and CEO at Particular Software. He is one of the world’s thought leaders in the areas of Service-Oriented Architecture and Domain-Driven Design, and a top-rated speaker at industry conferences.

He will be delivering the keynote at NSBCon in both London and New York City. You can also watch his most recent talk at Skills Matter where he discussed loosely-coupled orchestration with messaging.

1. What can people expect to take away from NSBCon in London?

NSBcon is the place to hear from the experts on message-driven and service-oriented systems, hearing about how companies are overcoming the challenges of migrating existing applications and code-bases to this new model, or the benefits of new technologies like event-stores and the cloud. Also, the best practices sessions will give users practical techniques they can start applying to their systems right away.

2. What new functionality in NServiceBus will developers be able to see this year?

The biggest improvement in the NServiceBus ecosystem this year is the release of the Particular Service Platform – a collection of applications for modeling, design, debugging, and monitoring of NServiceBus systems. After years of focusing on the absolute best code-first experience in NServiceBus, we’re now providing visualizations that give users the ability to see how messages flow through their systems as well as the state transitions of their long-running processes over time. We also have a major infrastructure improvement that we’re going to be unveiling at NSBcon, but we’re keeping that under wraps for now 🙂

3. With larger swarms of start-ups in London, can those operating in smaller enterprise systems still benefit from using NServiceBus?

There are actually several hundred start-ups already using NServiceBus around the world. One of the things that (apparently) we haven’t done a good enough job around is explaining that small start-ups can get a free license for NServiceBus. There’s absolutely no reason for them to waste their time figuring out how to set the correct transactional model for various queuing systems when they could be focusing on their next killer feature. Also, the new modeling tools around NServiceBus will get them started faster than ever.

4. Microservices seems to be the latest buzzword in software development. Many argue that this is essentially SOA. Where do you stand in this debate?

While I’m very happy to see a renewed discussion around service-oriented architectural styles, and I absolutely agree with the idea of decomposing a large-system into a collection of small, loosely-coupled pieces, I don’t think that it is necessarily wise to deploy each of those pieces as a separate runtime process. The overhead of remote communication can be thousands of times larger than in-process calls and should be considered carefully. The other thing that I find absent in the microservices discussion is the handling of data which, if not also decomposed into smaller parts, will undermine the ability of developers to achieve true loose-coupling with their microservices.

Don’t miss the opportunity to see Udi deliver the keynote talk at NSBCon 2014 – book your ticket now in London or New York!

While It’s Compiling: Skills Matter interviews Russ Miles

Russ Miles

While It’s Compiling is a series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.

This week we spoke to Russ Miles, Principle Consultant at Simplicity Itself. His experience covers almost every facet of software delivery – having worked across many different domains including financial services, publishing, defence, insurance and search. Most recently he has been an evangelist for microservices and formed the London μServices (Microservices) User Group.

Russ will be speaking  on the Origin of Services by Means of Natural Selection at μCon, London’s first microservices conference.

1. What projects are you working on right now?

Right now I’m working on a couple of projects that are distinct but related. One is a new microservice-based architected application that provides sentiment analysis based on a number of chat and social sources. The other is what I’m hoping will be a new open source project eventually, which takes some of the overhead associated with building antifragile software with microservices and makes it easier to work with.

Both projects are exciting, but obviously there is a lot to be considered in the latter project, especially when you want to get the advantages of microservices and antifragility without the necessary headaches of making that happen.

The aim will be to enable developers to focus on what they actually need to build, and the majority of the non-functional concerns associated with microservices and antifragility will be handled by the toolkit.

2. There has been a lot of talk about microservices lately. Why do you think it will be so important to the programming community?

Great question. I think the answer to this is probably four-fold, so please bear with me!

First, let’s dispel some confusion. Microservices are single-purpose services that typically expose a uniform subset of interfaces, such as messaging or HTTP, but there’s really no concrete restrictions there. The most useful analogy is to the unix command line tools.

The key power of unix command-line tools is that you can take these single-purpose, command-line tools and string them together, piping the output of one into the input of another  in order to deliver. Each of the tools does one thing, does it well, and supports a uniform interface to one another. The tools do not typically share state with one another, other than the uniform interface handoff, as they are connected together using pipes.

The exact same design approach is taken with microservices. By using a uniform interface, such as HTTP and REST as a style, or even Actors/Reactive applications, various applications can be simply composed in order to build an application.

This leads us to the first main important contribution from microservices: they are simple, single-purpose but autonomous services that aim to offer a uniform interface where appropriate. That’s not a landmark difference to other approaches, but it’s an important starting point.

The second contribution is more important, and has everything to do with beating what I call – based on a phrase coined by Rich Hickey – the ‘Elephant in the Standup’. The key feature of the Elephant is that all of the decisions and assumptions you’ve made prior to today that are manifest in your growing ‘legacy’ codebase will be in conflict with the change that you need to embrace today, tomorrow and going forward.

There are ways to manage the ‘elephant’. Evolving a codebase and system over time is difficult if all parts of it have to be evolved at the same rate. There are various modularisation techniques out there (OSGi springs to mind) that technically can help primarily with attempting to modularise and build services inside of an application. There is some merit to these approaches, and we’re looking to include some discussion on that at muCon for that reason.

From an architecture and design point of view, the Life Preserver tool that I teach in the “Antifragile Software with Microservices” course  provides an approach to modularity and design that can be applied regardless of the final deployment choice. These techniques prepare your existing monolithic applications better to accept and possibly even embrace change, but you can go further.

Microservices are a natural design approach that really give you the full power of embracing change as you are able to evolve parts of your application that change at similar rates, typically microservices, at the rate at which they need to evolve at. Breaking apart the monolith, a microservices approach takes the modularity that can be designed using the Life Preserver and applies it to the choices around version control and deployment strategies. This enables applications to evolve, even at runtime, without having to introduce onerous, monolithic and robust all-at-once strategies.

With microservices it is entirely possible to build applications that don’t just embrace change, but that can thrive on it. This is the essence of achieving antifragility in software, i.e. software where its architecture and design means that it gains from accepting the natural disorder and chaos of its runtime. Antifragility requires more in terms of non-functional requirements and even represents a different philosophical approach to software (more on that in my course and at muCon) but it is an extremely valuable step, as it has been shown to lead to the final important contribution of microservices: Enabling Speedy Innovation.

The outcome of achieving an architecture, design and runtime built of micro services that exhibit antifragile properties is that it encourages change rather than resists it. This is the big business payback of doing this work in the first place. Companies are seeing that they can compete through innovation faster than their competitors by adopting antifragiltiy and microservices, as their software can keep pace with the demand for change inherent in innovation. The software can change as fast as the business needs it to, and in the future (even, arguably, now) this will separate the winners from the losers.

So microservices is not just a buzz-word. It has real potential to tame and beat the elephant in the standup. What’s most exciting is that there is already evidence of this; we’re really not talking about vapourware promises for once!

3.  What was your first programming language? What drew you to it?

BBC Basic, and I believe I was drawn by one of the most truly awful teachers of computer science I ever had. I actually received a comment from my teacher on completing my GCSE work on a program in Basic that I should “stop, as I don’t understand code that much so you’ve achieved the best grade I can give already”. Probably my first experience of ‘overproduction’ as a Lean Waste!

After that, it’s probably best to talk about the language and platform that has somewhat ruled my life, which would be Java and the JVM. Despite a lot of general beating-up of Java – some of it justified – I am still very happy with the language, although on a regular basis I use any number of the following: JavaScript (Node, Browser), Ruby, Python, Groovy, Clojure, Scala, C#…In fact, due to microservices offering a wonderful mechanism to choose the right language and platform for a particular small service, I’ve found that knowing the strengths of various languages and platform pays huge dividends when building systems constructed that way. It’s only getting more fun, and my enthusiasm for different languages and platforms finds a pragmatic edge in microservices.

I’ve even coded using assembler and Ada (83 and 95 variants) for fast jets such as the Harrier and Typhoon, but I rarely shout about those languages too much these days other than to admit my age.

4. What is one piece of advice you’d like to give to new programmers?

Enjoy learning and read two books at the same time (not exactly at the same time, but in parallel). One book technical, one book as far out of your comfort zone as you can go. I’ve lost count of the number of times I’ve found something in a non-technical book, both fiction and non-fiction, that has influenced the architecture, design and code that I write.

Also remember that you are primarily writing code for other humans. It’s a skill that has a lot of similarities with writing articles and books, and so if you consider the reader as much as possible you’ll do well in this industry.

One last piece of advice: tests and test-driven development will help you write only the code you need, but it works hand-in-hand with the thinking and communication exercise that is architecture and design. The two work together; TDD does not supplant thinking! Remember, thinking is a massive amount of what we do, more than keyboard-ballet!

5. What would you like to ask the community?

What questions do you have on antifragility, building antifragile software, and microservices as an architecture and design approach?

I’m also always very interested in speaking to anyone who has thought about how one’s philosophy affects their software. I’m a big believer that our philosophical underpinnings, even if we don’t consciously analyse these things, lead us to the processes, architecture and design of how we deliver software. I’m always keen to hear people’s thoughts on that.

What do you want to know about antifragile software? Tweet us at #whileitscompiling or @skillsmatter.

Russ will be talking about the Origin of Services by Means of Natural Selection at μCon – check Skills Matter for updates and tickets!