Warning, Conferences ahead!

Update 24/08/2015 : some helpful people pointed out that I’ve missed a couple of other notable conferences here, including:


It’s almost that time of the year again, that last stretch of the year when we have so many good conferences in UK and Europe.




First we have quite a treat in Kats Conf, on the 12th Sep in Dublin. An unbelievable list of speakers include Joe Armstrong, Francesco Cesarinni, Edwin Brady, Amanda Laucher and Phil Trelford!

Sessions span across a number of FP languages – Erlang, Scala, F#, Idris to name a few.

What’s more, it’s great value for money. Ticket is only 25 euro, and if you fancy going to Erlang Factory Lite the day before you can even get a combo ticket for 50 euro.



Shortly after Kats Conf, there’s DevDay in Krakow on 17th and 18th Sep, with some well known speakers in the .Net space including our very own F# machine learning expert Mathias Brandewinder!



Then on the 26th Sep, there’s DDD East Anglia over in Cambridge, a one-day free event that’s organised by developers for developers.

The programme is not out yet but looks like I’ll be giving my “F# in the Real World” talk there.



Rounding off a rather busy September, there’s code.talks in Hamburg on the 29th and 30th Sep. I’ll be giving my “Tour of Programming Languages” talk there and I’m really looking forward to visiting Hamburg for the first time.




Hot on the heels of OSCON in Portland, it’s coming to Europe for the first time, in Amsterdam on 26th and 27th of Oct.

Some pretty cool tech companies will be there – GitHub, DataStax, Google, ThoughtWorks, PayPal, Heroku and Spotify to name a few! I will be talking about “Modelling Game Economy with Neo4j” there.

Rachel Reese from Jet.com is also coming over from the US to talk about building reactive services with F#!



CodeMesh has been my favourite conference the last couple of years and it’s the place to be to learn about emerging technologies and languages from some of the best people in the industry.

This year, you can learn from the likes of:

  • Sir Tony Hoare (Turing Award Winner)
  • John Hughes (QuickCheck)
  • Robert Virding (co-creator of Erlang)
  • Don Syme (creator of F#)
  • Joe Armstrong (co-creator of Erlang)
  • Evan Czaplicki (creator of Elm)
  • Stefan Karpinski (co-creator of Julia)
  • William Byrd (co-creator of miniKanren)
  • Bruce Tate (author of the 7 languages in 7 weeks books)
  • and F# superstars Phil Trelford and Tomas Petricek!

Seriously, if you’re looking for a conference that’ll challenge you intellectually (and honestly, hurt your brain a little!) then CodeMesh is the place to be on November 3rd and 4th in London!



Over in Malmo, there’s also Oredev from November 4th to 6th, which is a very well attended conference with thousands of attendees each year.

I have heard plenty of good things about Malmo and Oredev, and it was personally recommended by Phil Trelford so you just know it’s gonna be good!

And this year there’ll be a good F# presence, with Rachel Reese, Paulmichael Blasucci, Evelina Gabasova and myself all talking about F# 

Oh, and Adam Tornhill (who you might know as the author of Code as Crime Scene) will be there too.



Finally, BuildStuff is happening again from November 18th to 20th. It’s still early days and only a couple of speakers have been confirmed but already you can count the likes of Uncle Bob, Michael Feathers, Trisha Gee, Randy Shoup, Pieter Hintjens and Kevlin Henney amongst them.

Based on my experience from last year, I’m sure BuildStuff is going to be great again this year.


With so many great conferences coming up, I’m really excited to be able to learn from some of the best people in the industry and hope to catch you at some of these events!

NDC Oslo 15 – Takeaways from “Lean and Functional Programming”

Bryan Hunter has been responsible for organising the FP track at NDC conferences as well as a few others and the quality of the tracks have been consistently good.

The FP track for this year’s NDC Oslo was exceptional and every talk has had a full house. And this year Bryan actually kicked off the conference with a talk on how functional programming can help you be more ‘lean’.


History of Lean

Bryan started by talking about the history of lean, and whilst most people (myself included) thought the lean principles were created at Toyota, turns out it actually originated from the US.

At a time when the US workforce was diminished because all the men were sent to war, a group called the TWI (Training Within Industry) was formed to find a way to bring women into the workforce for the first time, and train them.

The process of continuous improvement the TWI created was a stunning success, before the war the US was producing around 3,000 planes per year and by the end of the war the US was producing 300,000 planes a year!

Unfortunately, this history of lean was mostly lost when the men came back from war and the factories went back to how they worked before, and jobs were prioritized over efficiency.

Whilst the knowledge from this amazing period of learning was lost in the US, remains of the TWI was sent to Germany and Japan to help them rebuild and this was how the basic foundations of the lean principles were passed onto Toyota.

sidebar: one thing I find interesting is that, the process of continuous improvement that lean introduces:

Lean Principles

is actually very similar to how deep learning algorithms work, or as glimpsed from this tweet by Evelina, how our brain works.


Bryan then outlined the 4 key points of lean:

Long term philosophy : you need to have a sense of purpose that supersedes short-term goals and economic conditions. This is the foundation of lean, and without it you’re never stable.

The right process will produce the right results : if you aren’t getting the right results then you’ve got the wrong process and you need to continuously improve that process.

Respect, challenge, and develop your people : and they will become a force multiplier.

Continuously solving root problems drives organizational learning.


Companies adopt lean because it’s a proven path to improving delivery times, reducing costs and improving quality.

The way these improvements happen is by eliminating waste first, then eliminating over-burden and inconsistency.


Lean Thinking

The so-called lean house is built on top of the stability of having a long-term philosophy and the process of continuous improvement (or Kaizen, which translates to changes for the better in Chinese and Kanji).

Then through the two pillars of Just-In-Time and Act on Abnormality we arrive at our goal of improved Delivery Times, Quality and reduced Costs.



A powerful tool to help you improve is “go and see”, where you go and sit with your users and see them use your system. Not only do you see how they are actually using your system, but you also get to know them as humans and develop mutual empathy and respect which leads to better communication.


Another thing to keep in mind is that you can’t adopt lean by just adopting a new technical solution. Often when you adopt a new technical solution you just change things without improving them, and you end up with continuous change instead of continuous improvement.

Functional programming fits nicely here because it holds up underneath the scrutiny of Plan-Do-Check-Act (PDCA). Instead of having a series of changes you really have to build on the idea of standard work.

Without the standard you end up with a shotgun map where things change, and improvements might come about (if you change enough times then it’s bound to happen some time, right?) but not as the result of a formalised process and are therefore unpredictable.


Seven Wastes

Then there are the Seven Wastes.


Overproduction is the most important waste as it encompasses all the wastes underneath it. In software, if you are building features that aren’t used then you have overproduced.

sidebar : for regular readers of this blog, you might remember Melissa Perris calling this tendency of building features without verifying the need for them first as The Build Trap in her talk at QCon London. Dan North also talked about the issue of overproduction through a fixation on building features in his talk at CraftConf – Beyond Features.


By doing things that aren’t delivering value you cause other waste to occur.


Transportation, in software terms, can be thought of as the cost to go from requirement, through to deployment and into production. DevOps, Continuous Integration and Continuous Deployment are very much in line with the spirit of lean here as they all aim to reduce the waste (both cognitive and time) associated with transportation.

Inventory can be thought of as all the things that are in progress and haven’t been deployed. In the waterfall model where projects go on for months without anything ever being deployed, then all of it will become inventorial waste if the project is killed. The same can happen with scrums where you build up inventory during the two-week sprint ,which as Dan North mentioned in his Beyond Features talk, is just long enough for you to experience all the pain points of waterfall.

You experience Unnecessary Motion whenever you are fire fighting or doing things that should be automated. This waste equates to the wear-and-tear on your people, and can cause your people to burn out.

Waiting is self-explanatory, and can often result from deficiencies in your organization’s communication and work scheduling (requirements taking too long to arrive whilst assigned workers are waiting on their hands).

Over processing is equivalent to the idea of gold plating in software. Although as Jett Atwood pointed out in his post here, refactoring can be thought of as gold plating in the purest sense but it’s also important in producing sane, maintainable code.


Lastly, we have Defects. It’s exponentially cheaper to catch bugs at compile time than it is in production. This is why the notion of Type Driven Development is so important, and the goal is to make invalid state unrepresentable (as Scott Wlaschin likes to say!).

But you can still end up with defects related to performance, which is why I was really excited to hear about the work Greg Young has done with PrivateEye (which he publically announced at NDC Oslo).



Bryan used the working of a (somewhat dysfunctional) warehouse to illustrate the problem of a large codebase where you have lots of unnecessary code you have to go through to get to the problems you’re trying to solve.image

sidebar : whilst Bryan didn’t call it out by name, this is an example of cross-cutting concerns, which Aspect-Oriented Programming aims to address and something that I have written about regularly.


One way to visualize this problem is through Value Stream Mapping.

In this diagram the  batch processes are where value is created, but we can see that there’s a large amount of lead time (14 days) compared to the amount of processing time (585 seconds) so there are lots of waste here.

As one process finishes its work the material is pushed aside until the next process is ready, which is where you incur lead time between processes.

This is the push model in mass manufacturing.

In software, you can relate this to how the waterfall model works. All the requirements are gathered at once (a batch process); then implementations are done (another batch); then testing, and so on.

In between each batch process, you’re creating waste.


The solution to this is the flow model, or one-piece flow. It focuses on completing the production of one piece from start to finish with as little work in process inventory between operations as possible.

In this model you also have the opportunity of catching defects early. By exercising the process from start to end early you can identify problems in the process early, and also use the experience to refine and improve the process as you go.

You also deliver value (a completed item) for downstream as early as possible. For example, if your users are impacted by a bug, rather than have them wait for the fix in the next release cycle along with other things (the batch model) you can deliver just the fix right away.

Again, this reminds me of something that Dan North said in his Beyond Features talk:

“Lead time to someone saying thank you is the only reputation metric that matters.”

– Dan North

And finally, you can easily parallelise this one-piece flow by having multiple people work on different things at the same time.


Bryan then talked about the idea of Single-minute Exchange of Die (SMED) – which is to say that we need an efficient way to convert a manufacturing process from running the current product to running the new product.

This is also relatable to software, where we need to stay away from the batch model (where we have too much lead time between values being delivered), and do as much as necessary for the downstream and then switch to something else.

sidebar : I feel this is also related to what Greg Young talked about in his The Art of Destroying Software talk where he pushed for writing software components that can be entirely rewritten (i.e. exchanged) in less than a week. It is also the best answer to “how big should my microservice be?” that I have heard.


You should flow when you can, and pull when you must, and the idea of pull is:

“produce what you need, only as much as you need, when you need”

– Taiichi Ohno

when you do this you’re forced to see the underlying problems.


With a 2 week sprint, there is enough buffer there to mask any underlying issues you have in your process. For instance, even if you have to spend 20 mins to fight with some TeamCity configuration issue then that inefficiency is masked by you working just a bit harder. However, that problem is not fixed for anyone else and is a recurring cost that your organization has to pay.

In the pull model where you have downstream waiting on you then you’re forced to see these underlying problems and solve them.


There’s a widespread misconception that kanban equals lean, but kanban is just a tool to get there and there are other tools available. An interestingly, Taiichi Ohno actually got the idea for kanban from piggly wiggly, based on the way they stock sodas and soup.

Another tool that is similar to kanban is 5S.



Act on Abnormality

A key component here is to decouple humans from machines – that you shouldn’t require humans to watch the machines do their job and babysit them.

Another tool here is mistake-proofing, or poka yoke. If there’s a mistake that can happen we try to minimize the impact of those mistakes.

A good example is the design of the manhole cover:


which is round so that it can’t fall down the hole no matter which way you turn it.

Another example is to have visual controls that are vary obvious and obnoxious so that you don’t let problems hide.


I’m really glad to hear Bryan say:

“you shouldn’t require constant diligence, if you require constant diligence you’re setting everyone up for failure and hurt.”

– Bryan Hunter

which is something that I have been preaching to others in my company for some time.

An example of this is in the management of art assets in our MMORPG Here Be Monsters. There were a set of rules (naming conventions, folder structures, etc.) the artists have to follow for things to work, and when they make a mistake then we get subtle asset-related bugs such as:

  • invisible characters and you can only see his/her shadow
  • a character appearing without shirt/pants
  • trees mysteriously disappearing when transition into a state that’s missing an asset

So we created a poka yoke for this in the form of some tools to decouple the artists from these arbitrary rules. To give you a flavour of what the tool did here’s some screenshots from an internal presentation we did on this:



When you do have a problem, there’s a process called the 5 Whys which helps you identify the root cause.



Functional Programming

The rest of the talk is on how functional programming helps you mistake-proof your code in ways that you can’t in imperative programming.



A key difference between FP and imperative programming is that imperative programming relies on mutating state, whereas FP is all about transformations.

This quote from Joe Armstrong (one of the creators of Erlang) sums up the problem of mutation very clearly:

“the problem with OO is that you ask  OO for a banana, and instead you get a Gorilla holding the banana and the whole jungle.”

– Joe Armstrong

With mutations, you always have to be diligent to not cause some adverse effect that impacts other parts of the code when you call a method. And remember, when you require constant diligence you’re setting everyone up for failure and hurt.

sidebar : Venkat Subramaniam gave two pretty good talks at NDC Oslo on the power and practicality immutability and things we can learn from Haskell, both are relevant here and you might be interested in checking out if you’re still not sold on FP yet!


In C#, making a class immutable requires diligence because you’re going up against the defaults in the language.


sidebar : as Scott Wlaschin has discussed at length in this post, no matter how many FP features C# gets there will always be an unbridgeable gap because of the behaviour the language encourages with its default settings.

This is not a criticism of C# or imperative programming.

Programming is an incredibly wide spectrum and imperative programming has its place, especially in performance critical settings.

What we should do however, is to shy away from using C# for everything. The same is true for any other language – stop looking for the one language that rules them all.

Explore, learn, unlearn, there are lots of interesting languages and ideas waiting for you to discover!


How vs What

Another important difference between functional and imperative programming is that FP is focused on what you want to do whereas imperative forces you to think about how you want to do it.

Imperative programming forces you to understand how the machine works, which brings us back to the human-machine lock-in we talked about earlier. Remember, you want to decouple humans from machines, and allow humans to focus on understanding and solving the problem domain (which they’re good at) and leave the machine to work out how to execute their solution.


Some historical context is useful here, in that back in the days when computers were slow and buggy, the hardware was the bottleneck. So it pays to have the developer tell the computer how to do our computations for us, because we knew better.

Nowadays, software is the thing that is slow and buggy, both compilers and CPUs are capable of doing much more optimization than most of us can ever dream of.

Whilst there are still legitimate cases for choosing imperative programming in performance critical scenarios, it doesn’t necessarily mean that developers need to write imperative code themselves. Libraries such as Streams is a good example of how you can allow developers to write functional style code which is translated to imperative code under the hood. In act, the F# compiler does this in many places – e.g. compiling your functional code into imperative while/for loops.


Another way to look at this debate is that, by making your developers deal with the HOW as well as the WHAT (just because you’re thinking about the how doesn’t mean that you don’t have to think about the what) you have increased the complexity of the task they have to perform.

Given the amount of cognitive resources they have to perform the task is constant, then you have effectively reduced the likelihood your developers would deliver a piece working software that does the right thing. And a piece of software that does the wrong faster is probably not what you are after…


p.s. don’t take this diagram literally, it’s merely intended to illustrate the relationship between the three things here – cognitive resources, complexity of the problem and the chance of delivering a correct solution. And before you argue that you can solve this problem by just adding more people (i.e. cognitive resources) into the equation, remember that the effect of adding a new member into the group is not linear, and is especially true when the developers in question do not offer sufficiently different perspective or view point.


null references

And any conversation about imperative programming is about complete without talking about null references, the invention that Sir Tony Hoare considers as his billion dollar mistake.

sidebar : BTW, Sir Tony Hoare is speaking at the CodeMesh conference in London in November, along with other industry greats such as John Hughes, Robert Virding, Joe Armstrong and Don Syme.

In functional languages such as F#, there are no nulls.

The absence of a value is explicitly represented by the Option type which eliminates the no. 1 invalid state that you have to deal with in your application. It also allows the type system to inform you exactly where values might be absent and therefore require special handling.


And to wrap things up…





My adventure with Elm @ NCrafts

Yan Cui - MY ADVENTURE WITH ELM from NCRAFTS Conferences on Vimeo.

with accompanying slides here:

All the FP talks at NDC Oslo

Great news, recording of all the talks at this year’s NDC Oslo has been uploaded to Vimeo!

It’s a lot of videos to go through, so I’ve curated all the talks from the FP track this year, including my new talk “A tour of the language landscape” where I covered some interesting ideas and concepts spanning across a number of languages – F#, Clojure, Go, Rust, Idris, Elm and Erlang.

Learn to Learn

Being a responsible speaker, I have started preparing my talk – A tour of the language landscape – for NDC Oslo months ahead of time! When I first came up with the idea for this talk, I asked on Twitter if anyone else thought it was a good idea. Phil made a great point about including some information on how I go about learning a new language.


I came across this TEDx talk by Josh Kaufman a while back and found it useful in helping me formulate a learning strategy that works for me.

Truth about the 10,000 hours rule

In the talk, Josh debunked the often misquoted 10,000 hours rule. When the study was first published, the finding was that it takes 10,000 hours of deliberate practice to reach the top of an ultra-competitive field. But through a collective Chinese whisper the message was warped into ‘it takes 10,000 hours of deliberate practice to be good at something’.

Instead, Josh found that researches suggest 20 hours is all it takes for you to be reasonably good at something so long you make those hours count.


This is important, because for us busy programmers – who, by the way, have a tendency to work long hours – the time to learn new skills is both limited and necessary given how fast our industry moves.

4 steps to learn

Josh proposed these 4 steps to learning anything.


Deconstruct the skill

Most things we consider as skills are actually bundles of skills. The more we are able to break them up into smaller skills the better we can decide which of them actually helps us achieve what we want out of our learning. We can then prioritise the skills that are most useful to us and improve our ability in the least time possible.

For learning a programming language, you can deconstruct most languages into smaller chunks:

  • variable assignment
  • common data types
  • control flows (if-else, loops, recursions, etc.)
  • working with collection types
  • working with strings
  • error handling
  • concurrency

Most introductory books and tutorials follow this structure already.

Learn enough to self-correct

You should first focus on getting to the point where you can self-correct and self-edit as you learn. For learning a programming language, I interpret this point as:

  • know how to compile and run your code
  • able to put simple programs together, and tweak it to start getting a ‘feel’ of it

Again, most introductory books and tutorials follow this pattern already and have you build a Hello World example very early on.

Remove practice barriers

Remove distractions – TV, internet, twitter, etc. – so that you can focus on learning. This can be hard when distractions are all around us and so readily available!

I once heard a story about John Carmack that, before a new project, he’d check in to a hotel with a bunch of good books and literally cut himself off from the outside world for days so he can soak up the ideas and inspirations before starting any work on the project.

I’m not saying that you should do the same, obviously different approaches work for different people. Personally I’m most effective between the hours of 10PM and 2AM because my wife goes to bed early and I’m able to just zone out.

I’m not a heavy Twitter user, or any other social network for that matter, so they’re not a problem for me.

On the other hand, comic-based TV shows is my poison – The Flash, Gotham, Arrow, Agents of SHIELD, etc. To limit the amount of disruption these bring, I binge watch them in one night so I can have the rest of the nights that week for more constructive uses.

Practice at least 20 hours

Josh raised a good point that, for most things you learn, there is a frustration barrier – the moment when we become consciously incompetent and realise how little we know and how much more we need to learn.


It’s not a great feeling as no one likes to feel stupid, and this is often the point where we lose our momentum and derail our hard-earned progress.

Which is why it’s important that we pre-commit at least 20 hours of our time, so that if and when we hit this frustration point we have a good reason to push on since we already budgeted 20 hours anyway.

Set your goal

Before you start investing a minimum of 20 hours into learning a new language, it helps if you could decide what you want to get out of the process. Depending on your situation and needs this could be quite different, e.g.

  • are you looking to move to a different language stack and trying to make yourself employable?
  • are you trying to understand the hype around a new language and see what it’s all about?

Personally, most of my learning is aimed at expanding my horizon and allowing me to see beyond the possibilities and options I have at my disposal with the stack that I work with day-to-day.

Other times I might have specific goals of what I want to be able to do in that new language, for instance:

  • I learnt Dart as a replacement to JavaScript for my web development needs
  • I learnt Elm to be better acquainted with functional-reactive programming (FRP) and with the aim of being able to make games using FRP

Prioritise learning a new paradigm

One mistake that I see many people make is to choose to learn a new language over a new paradigm. For example, making the jump from C# to Java is a relative easy one, but at the end of day you have learnt a new syntax without necessarily taught yourself a new way to solve problems.

Learning a new paradigm on the other hand, fundamentally change the way you see programming and allow you to see new ways to solve problems. From personal experience, each time I ventured into a new paradigm – Functional Programming, Aspect-Oriented Programming, Functional Reactive Programming, etc. – has allowed me to see programming in a new light.

If you’re interested in exploring some less travelled roads, check out these three paradigms recommended by John Croisant.

These two books by Bruce Tate are also a great source for exploratory learning:

7-langs-7-weeks  7-more-langs-7-weeks

And finally, I leave you with a great quote from none other than Alan Perlis.

A language that doesn’t affect the way you think about programming, is not worth knowing.

– Alan Perlis

Happy learning!