QCon London 2015–Takeaways from “Small is Beautiful”

You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!

From the first day of QCon London, I really enjoyed Kevlin Henney’s Small is Beautiful talk. Titled after E.F. Schumacher’s book (below) of the same name, the title itself should give you a pretty good idea of what to expect from this talk.



I’m a big fan of Kevlin, and his “Seven Ineffective Coding Habits of Many Programmers” talk at BuildStuff was the inspiration behind my parody post for the F# advent calendar last year. And as ever, Kevlin has plenty of well-applied, memorable quotes, starting with this one:

Sustainable development is development that meets the needs of the present without compromising the ability of future generations to meet their own needs.

– the report of the Brundtland Commission

when applied to software development, my interpretation of it is : “don’t take on more technical debt than you can reasonably pay back in the future in favour of short-term gains”. Which is nicely backed up by this tweet:



On the other extreme of the spectrum, you have people who are so concerned about future needs they end up completely over-engineering their solution to cope with this uncertainty and end up with projects that are delayed or worse, never delivered.



You should think of software as products, not projects.

If software are projects then they should have well-defined end state, but most often, software do not have well-defined end state, but rather evolved continuously for as long as it remains desirable and purposeful.


Despite its naivety when it comes to measuring complexity, lines-of-code is still a good metric to consider as it fits nicely with our main constraint as developers – our working memory.


There’s a learnt complacency amongst many developers that has allowed them to rest on their laurels and accept large codebases as a reality that cannot be challenged.

Kevlin showed a perfect counter-example of a computer chess program that is less than 512-bytes! Even the Unix 6 OS was less than 10k lines of code long, which is a fraction of the size of many modern day software.


(from Alan Kay’s 2011 talk, Programming and Scaling)


Creativity needs a boundary. Without any boundaries, a painter might be lost if you just ask him to “draw a picture”, and would you create anything more than a “hello, world!” application if asked to just “write a program”?

As Dennis Ritchie and Ken Thompson pointed out, size constraints played a key role in encouraging their creativity and come up with designs that are both elegant and small:

There has always been fairly severe size constraints on the Unix operating system and its software. Given the partially antagonistic desires for reasonable efficiency and expressive power, the size constraint has encouraged not only economy but a certain elegance of design.

– Dennis Ritchie and Ken Thompson

“The UNIX Time-Sharing System”, CACM

One reason for systems to become large is because we expect them to be that way without challenging that belief, putting boundaries pushes us to challenge those complacencies.

Kevlin also pointed out another good point – the more time you spend working on a project, the more the endowment effect kicks in and we become less inclined to change.


Conway’s law

organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.

– M. Conway

tells us that, another reason for systems to become large is because of the way they are staffed. Ironically, staffing decisions are usually taken at the point of your greatest ignorance – at the start of a project.

In other words, if you hire 100 people to work on a system, then you put in motion the events that will result in a communication structure consisting of 100 people, and the size of the system you get at the end becomes a self-fulfilling prophecy.


Software development does not have economies of scale.

Development has diseconomies of scale.

– Allan Kelly



You should be aware of code that serves no purpose.

Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose.

Cargo cult programming can also refer to the results of applying a design pattern or coding style blindly without understanding the reasons behind that design principle.

– Wikipedia

What followed was a hilarious example of “enterprise” code at its finest – FizzBuzzEnterpriseEdition, seriously, check it out, I guarantee it’ll be the best thing you’ll see today!


Kevlin then retold the well-known tale of how Knight Capital Group lost $460 million in 45 minutes from a different perspective to highlight the potential danger of leaving old code that no longer serve any purpose around.

A classic case of “what’s the worst that could happen?”


And if you need any more convincing about removing redundant/unused code.

Our task is not to find the maximum amount of content in a work of art.

Our task is to cut back content so that we can see the thing at all.

– Susan Sontag

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

– Antoine De Saint-Exupery



And finally, Kevlin’s offered one last bit of insight – system failures don’t usually happen because of one thing, they usually occur as the result of multiple failures.

This is, interestingly, echoed by none other than Man Utd’s legendary manager Sir Alex Ferguson who once said that goals are usually conceded as the result of multiple failures throughout the build-up play even if it ends with an individual’s error.


Slides for Small is Beautiful

Liked this article? Support me on Patreon and get direct help from me via a private Slack channel or 1-2-1 mentoring.
Subscribe to my newsletter

Hi, I’m Yan. I’m an AWS Serverless Hero and I help companies go faster for less by adopting serverless technologies successfully.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.

Hire me.

Skill up your serverless game with this hands-on workshop.

My 4-week Production-Ready Serverless online workshop is back!

This course takes you through building a production-ready serverless web application from testing, deployment, security, all the way through to observability. The motivation for this course is to give you hands-on experience building something with serverless technologies while giving you a broader view of the challenges you will face as the architecture matures and expands.

We will start at the basics and give you a firm introduction to Lambda and all the relevant concepts and service features (including the latest announcements in 2020). And then gradually ramping up and cover a wide array of topics such as API security, testing strategies, CI/CD, secret management, and operational best practices for monitoring and troubleshooting.

If you enrol now you can also get 15% OFF with the promo code “yanprs15”.

Enrol now and SAVE 15%.

Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.

Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!

Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!