QCon London 2015–Takeaways from “Small is Beautiful”

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.

Links

Slides for Small is Beautiful