Check out my new course Learn you some Lambda best practice for great good! and learn the best practices for performance, cost, security, resilience, observability and scalability.
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.
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.
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.
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
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.
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 new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. 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!
Are you working with Serverless and looking for expert training to level-up your skills? Or are you looking for a solid foundation to start from? Look no further, register for my Production-Ready Serverless workshop to learn how to build production-grade Serverless applications!
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are wrong about serverless and vendor lock-in
- You are thinking about serverless costs all wrong
- Just how expensive is the full AWS SDK?
- Many faced threats to Serverless security
- We can do better than percentile latencies
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong
- Top 10 Serverless framework best practices