The Mastodon in the room: Why Clojure?

Mastodon C advertises itself as a ‘Clojure shop’ when talking to clients and partners, but let’s delve a bit deeper into what this means and why we believe it’s a key advantage for us. Ultimately, it comes down to a simple idea:

“Simplicity is hard work. But, there’s a huge payoff. The person who has a genuinely simpler system – a system made out of genuinely simple parts, is going to be able to affect the greatest change with the least work. He’s going to kick your ass. He’s gonna spend more time simplifying things up front and in the long haul he’s gonna wipe the plate with you because he’ll have that ability to change things when you’re struggling to push elephants mastodons around.”
Rich Hickey, Creator of the Clojure programming language (edited for effect)


Clojure is a computer programming language that promotes simplicity, whilst simultaneously being incredibly powerful and broad. It hails from a family of languages known as LISPs (LisProcessor), which are famous for their distinctive, fully parenthesized Polish prefix notation. It looks a bit like this…

(require '[clojure.string :as string])
(defn say-hello [name]
  (->> name
       (println "Hello")))

#=> (say-name "archibald")
"Hello Archibald"

If you’ve ever seen code from other languages, such as JavaScript or Python, you’ll notice immediately that this is aesthetically very different. However, like any programming languages, once you’ve learnt the nuances and the idioms, writing code that is concise yet expressive becomes quite straight-forward. Clojure is especially geared toward a style of programming known as declarative, whereby a programmer, rather than solve problems imperatively (“do this, then this”) is more descriptive (“change this data to look like this”), allowing the underlying language and/platform (the JVM in Clojure’s case) to do the heavy-lifting. The result is often much less actual code – and the less code there is, the less there is to go wrong!

Clojure is predominantly used as a ‘server’ language which means that it’s usually the workhorse at the bottom of a technology stack, doing all of the business logic, logging, management and logistics. This suits us quite nicely, as this is where most of the Mastodon C magic tends to happen –  reading in data, crunching lots of numbers, managing distributed computations across the cloud. Having all of our solutions written in Clojure means that we significantly reduce the effect of “silo-ing” people into specific projects. One person can easily move between jobs and this is something we actually mandate as part of our support process.

Pretty things

Recently there has been a big movement to bring Clojure to more platforms. Where once it was almost exclusively big, beefy servers, Clojure is now also available in your browser via ClojureScript – a near-perfect reproduction of the Clojure language which transpiles to JavaScript. This opens up a vast amount of opportunities for development across browser, mobile and desktop, as well as allowing seamless integration with lots of powerful and popular JavaScript libraries – such as React, jQuery, D3 and many more. It’s completely possibly now to write entire client-side web applications using ClojureScript – and many have.

Considering Mastodon C is already bursting with experienced Clojure developers, using ClojureScript for our frontend work is a total no-brainer, and of course comes with the added benefit that – once again – no one is left-behind when it comes to rolling up their sleeves and contributing to the code. There is no “server team” and “frontend team” as is so typical at most polyglot organisations – everyone does everything.

Once more, with feeling

It’s important to note that although our preference lies firmly in Clojure and ClojureScript, we aren’t scared of cutting our teeth on other languages, especially if they are designed for and excel at a specific task – R is a good example of this. However, the benefits of working in a predominantly Clojure organisation are paying dividends for us:

Further reading/listening

We’re on the Whitehall steering group of “digital and data visionaries”

It was announced yesterday that Fran, our CEO, will be on the new steering group of “digital and data visionaries” helping the UK government become more and more data-driven. We’re obviously very excited about this – both because it’s an honour to be asked to participate, and because we’re genuinely keen to put data to work in a way that really affects our lives for the better.

The full list of members is:

  • Sir Nigel Shadbolt from the ODI
  • Mustafa Sulyman from Google DeepMind
  • Fran Bennett from Mastodon C
  • Xavier Rolet from the London Stock Exchange
  • Mark Thompson from Judge Business School
  • Dame Fiona Caldicott, former Chair of the National Information Governance Board for Health and Social Care

City modelling MVP – develop and share demographic projections

We’re getting very close to launching the minimum viable product (MVP) version of Witan, the city modelling platform we’ve been working on since this summer.

The MVP will be focussed on running and evolving demographic models – having a picture of how many people, of what type, will be where, in a city, underpins all sorts of other critical services, so is a good place to start with creating a data-driven, legible model of the city. Plus, it’s helping us to develop a really great user experience for the key parts of city modelling:

  • Working with input data from many places – in this case, 33 London Boroughs, providing various housing scenarios as inputs
  • Forecasting based on variable assumptions, and making those assumptions transparent – for example, how high migration is expected to be in future years
  • The ability to keep some scenarios and data private, but also to share your scenarios with colleagues and keep track of how they are developed over time as policy or knowledge evolve

The interface is pretty clean and simple at the moment. We’re happy with how it’s coming together, and excited about having it live before Christmas – sneak preview below.


The team has also been busy on personal projects – while building Witan v1, we’ve also manufactured one and three-quarters babies between us.


If you’d like to keep up with Witan progress, request a demo, or request more very cute baby photos, please do get in touch.

How we’re building a new city platform

As we mentioned earlier on the blog, we’re working on a very big and ambitious project to create a new city modelling platform, Witan, with London as the first test bed.

Since there is so much that could be done in this field, and so many possible ways to do it, there are some tough choices for us to make, to ensure that the platform works and is widely adopted, both in London and in other world cities.

Oh, if only.

Oh, if only.

We wish that new product development was predictable – a straight line from seeing a user need, to building a tool which meets that need, then selling it to lots of other similar users. Unfortunately, it’s rarely that simple or predictable.


There’s no easy way to make that path predictable – but we can do things which reduce the overall risk, and this is a big part of our lives at the moment. This post outlines how we’re tackling the challenge for Witan, drawing some inspiration from the stellar resources shared by the GDS with their user research method wiki, how companies like Spotify build their products, and good agile (with a small A) practices.


Understanding the problem first

If we start by casting our net wide early on, we can improve our understanding of the problems our users have, to end up with a larger set of user needs.

We can’t serve every need, so we validate and prioritise which needs we want to meet with further research. At this point we focus on the problem, not on how we’d solve it.

Choosing the smallest way to meet a need

When we  have a smaller set of needs we’re aiming to meet, we diverge again, to come up with solutions to the problems we’ve decided to target. We’d typically describe these as user stories.

Checking we’ve actually solved it

We choose the smallest subset of user stories possible to deliver to users, build a solution which meets those needs, and see how well it works for the users in reality. When we’re building those solutions, we use multi-skilled teams because we want to minimise handoffs between experts, and we get our team to work with directly with users in order to create a sense of empathy and make sure that the technology really meets their needs.

And repeat…

Inside Mastodon C, we’ve been working in weekly iterations for a while: each week we demo what we’ve made, and then we plan what we’ll do the following week. One key thing we’re trying now, is using the mental model above to decide what activities in our ‘toolbox’ are most appropriate for that week.

Early on – when our focus is discovery

Early on – when our focus is discovery

Early on – when our focus is discovery

Early on in the project, most of our time is spent generating ideas, and exploring them, so we have a set of needs to validate, most of our activities are in the left hand side of our ‘toolbox’.


As we learn more, we’ll move more of our efforts to activities in the middle, where we’re validating our understanding of user’s needs, and see how they currently try to solve their problems themselves. It’s not uncommon for some of our team to focus on activities on the left after discovering something new, while the rest focus on the middle, on problems that we have a better understanding of. Again, we share what we learn each week in a show-and-tell like session, (but with added cake).

Testing out a solution to a problem we feel we understand

Testing out a solution to a problem we feel we understand

Later on, when we’re confident we understand enough of the problem to build a solution to it, we’re likely to be spending most of our time on activities on the right.

That is, until we discover something interesting enough to warrant spending some time using tools from the left hand side of our toolbox again. In some cases, we might discover a killer new feature that makes sense to add to what we have built already.

In others, we might discover the beginnings of a new product that is interesting, but not key to meeting the needs of the users we’re designing for right now. We’ll save it for later to see if it comes up again, at which point we’ll make a call about whether we should investigate further.

Well, that’s the plan at least

We’re working on one of the most complex problems we’ve ever come across, in one of the greatest cities on earth – if you’d like to see how we get on, watch this space.

Witan – the flexible city modelling platform

Screen Shot 2015-08-19 at 11.08.56

As Fran mentioned in her previous blog post, Mastodon C is working together with the Greater London Authority to develop a flexible approach to city modelling. The aim is to take forecasting beyond the limitations of Excel, while providing modellers with the benefits of sophisticated data management tools, such as version control, security levels and scaling to very big or complex datasets.

We are now working on the first features of this platform together with the GLA demography team. Population projections are vital to London planning and provides a base for the London Plan, the Mayor’s strategic plan for London up until 2036. London population projections are also used by multiple departments within the GLA and underlie many other models, and including these models early on means that the Witan platform can be beneficial throughout the organisation.

Another feature we are implementing is an interface for London boroughs to input data and run population projection scenarios themselves, without having to rely on GLA modelling resources. The platform thus provides boroughs with a powerful tool to take charge of their own, local, modelling requirements.

Going forward, this interface can be used for other city modelling purposes and be expanded to other stakeholders beyond the London boroughs, providing the ability to run different models and access a host of datasets, both open and private, to play out city modelling scenarios.      

We will be implementing these first features of Witan in the autumn and hope to provide updates on the platform build as we progress. The platform will be built using open source and interested parties will be able to access the platform code through our Github account.

By the end of the year, the demographic forecasting modules of the platform will be in public beta, and we’d love to start working with more interested users – please do get in touch at if this sounds like it would be useful for you!

A Next-generation City Modelling Platform is born… (well, conceived… blog post #1 in a series)

[cross posted from the London DataStore blog]

There’s been a lot of discussion, on this blog and elsewhere, of what to actually do with city data once it’s out in the world. We think that, given the capital’s booming population and the consequent policy focus on addressing a wide range of infrastructure needs, one of the most important applications is using data (both open data, and the more private stuff) to gain insight into how the city is functioning right now, how this could potentially change based on a range of inputs, and to ultimately set out different scenarios for its future.

I’m very pleased to say that our company, Mastodon C, is going to be working with the GLA in 2015 and 2016 to try and do just this: to prototype a city data platform which will help the GLA’s modelling experts, data analysts, policy makers, and the public to integrate and make sense of different types of model and forecast, in order to explore scenarios for the future of London.

We plan to make use of the best of modern “big data” and web-based technologies, to make it easier for:

  • experts to ‘look into’ and adjust the equations, assumptions and connections of their models (without the need for programming skills), and take advantage of functions they don’t have at the moment, like version control and the capacity to scale to very big or complex datasets and simulations
  • policy makers to explore scenarios much more widely without the need to engage directly with the equations.
  • all of us to be able to see what’s being planned and what the thought process behind that is, through a graphical interface.

The platform will build on open source technology, will be open source itself, and will provide an open API interface to read data from and publish data to other systems.

This is all made possible by Innovate UK’s SBRI programme, which is funding the prototype development – which gives us a really unusual and exciting opportunity to tackle some really important problems using the latest technology.

We are, of course, very excited about this whole thing, and will be blogging regularly as things unfold – our first job being to spend some quality time with the GLA’s experts to understand what they really need from such a platform. Watch this space for more news!

City Modeller/Data Scientist Job

We’re looking for an experienced City Modeller and Data Scientist to help us work on an upcoming project. More details are below.

Who we are

Mastodon C are agile big data specialists. We offer the open source technology platform and the skills to help our clients realise the potential of their data. We work in particular in applying data to areas where we think we can have a positive impact on the world, like sustainability, health, and built environment.

You will act as our inhouse city modelling expert for a major new product, applying big data, open data, and analytics technologies to improve city planning. We’ll be working with one major city as a test client, and hope to be bringing the product to a wider market in 2016.

You will in particular be responsible for:

  • Interacting with users and clients to understand their challenges and goals
  • Adjusting generic models for city scale purposes
  • Advice on alternative models to use for various city challenges
  • Disseminate knowledge around urban planning and city modelling throughout the team
  • Thinking through data workflows that will be intuitive for both technical and non-technical users
  • Querying data sources and coming up with recommendations for data usage and data related challenges
  • Working closely with the development team to create integrated city model structures – you will be specialising in the mathematics of the various city models, but you will also get involved with developing features end-to-end
  • Thinking through data workflows that will be intuitive for both technical and non-technical users
  • Working with our team to create meaningful, interactive visualisations of modelling results and forecasts

You will work day-to-day with the software development team and UX and UI focused staff, who you will collaborate with to design and implement the product.

Who you are

Our ideal person for this role would:

Must Have:

  • Have a Masters or PhD in urban planning, ecological modeling or similar.
  • Have had exposure to a wide range of city related models, such as population, pollution, transport and housing, and knowing the pros and cons of various model approaches
  • Be keen to learn about new areas of city modelling
  • Be excited to share their knowledge with the team
  • Have good communication skills – able to listen to users and clients and understand their challenges and goals and being able to communicate complex structures and models to non-technical users
  • Be interested in and excited about applying data and analytics to important issues in the world

Nice to Have:

  • Have experience with Javascript, HTML, and CSS, and be comfortable learning other new languages
  • Have experience with web-based data visualisation
  • Have experience with ETL or big data technologies (spark, hadoop, other)
  • Experience in or interest in clojure

Salary and work environment

We are based in Fitzroy Street, near Euston, London. We’re also happy to discuss part-remote or part-time arrangements if those are important for you.

We’re a small and very consultative team, which means that every member has a big influence on how things run and has a lot of control over the way they work.

The salary for this role is up to £40,000 per year. Our preferred start date is 1st June.

If this looks like your kind of a job, please contact us at with a CV (and, if possible, recent code or project examples) and we’ll talk.

Please note that you need to be eligible to work in the UK to apply for this position.

No agents please.