At heart, I suspect we're all playing with Lego

2/5/2014

I'm constantly on the hunt for ways to reduce what look like extremely complex activities and reduce them down to their core, and very few activities come much more complex than the development of software. It is in the essence of such activities that a person's motivations, rationale and uptime view of value can be understood, and so the effort of analysis seems worth it.

However I'm fairly sure there's a simple set of urges behind the majority of software developers out there, and they are:

We like being creative
We like building stuff
We used to play with Lego (other brands of build-it-yourself-toy are also available).

The Urge to Build Stuff

As software developers it's often hard to see what we're actually building. We work in an ephemeral substance that often only we understand, which tends to contribute to our relative lack of contribution at the average dinner party.

Under the surface though, we are all builders, and I suspect that we have similar mental models for what we're building that make it easy for us to adopt certain techniques, but not others.

Why OO is SO popular

Object Orientation (OO) is about creating building blocks, objects, that can be fitted together to implement some useful functionality. Despite many attacks over recent years, OO is still the dominant force for thinking and building software in the IT industry, and one factor I believe is its strong analogy to a friendly memory from our childhoods... namely, Lego.

OO is Lego you get paid to build

So here's the rub. I think that the majority of software developers are at heart quite surprised, but loving the fact, that they are effectively being paid to work with Lego.

Admittedly the Lego set has become a LOT more complex, with pieces of all sorts of custom shapes and only a few guidelines for how to make good pieces that can be comprehended by other people, but still ... we're playing with Lego and getting paid for the pleasure.

Problematic for Functional Programming

And so we come to Functional Programming. Functional Programming has been around for years, come and gone with the tides, and is currently back with the force of simplifying software in many ways. This is a good thing but it does face challenges with adoption, and one challenge will become evident if you buy my argument that software development is approached like building with Lego, namely:

Functions are not easily analogous Lego Blocks

This is not to say that functional programming is not valuable and has some real potential in simplifying the software we need to write. It's just that the analog of having a thing, an object, hits out respective Lego-building buttons; having an activity, a function, doesn't so easily cut it in our mental model.

Aside from this, one slightly positive outcome of the friction between functional programming and Lego-building-mental-models, is that there is a certain smugness to having got to grips with functional programming. A smugness that transcends the language chosen. It is the smugness that comes from realising on some deep level that we've broken out of our original habits, and found a whole new set of Lego pieces.

We've jumped from Duplo to Lego Technics.

Lego does not equal Easy!

At first glance it can seem like I'm entirely trivialising software development to the simple activity of playing with Lego, but that's not my intention. Software development is an intense, intellectually challenging activity that involved research and development.

I suspect that the joy of building software comes from a similar joy that occurs when building something with Lego, with the same dangerous urges to build something overcomplicated to express our smartness.

My take is that the Lego analogy might have some deep ramifications for understanding why our software tends to surprise us in odd ways, which is one purpose of an analogy in the first place.

So, how's your Lego building going today?

1 Comment

Paul Bowler

2/6/2014 08:17:47 pm

Like Lego, OO was created to help kids model the 'real world' (whatever that is), although using code bricks rather than plastic ones. This idea also fits very neatly with the natural human disposition for categorisation and metaphor - the very foundations of language itself. Philosophy and technology meet head-on.

This is all very well, but a lego model, once built, is rather... boring; it just sits there looking shiny and colourful. If you want it to do anything you have to interact with it yourself - I believe this is called 'play' - or upgrade to the Technic sets which, along with the standard bricks, include functional blocks that perform generic actions such as movement, producing sound and light, or simple logic operations.

The world of software object orientation also shares this pattern - where interactions with our object model are performed through methods encapsulated within other objects. The resulting set of design patterns describe common scenarios and ways of linking objects to each other using a set of simple, generic interfaces. We can then create and share our own software components for reuse without having to reinvent it each time. Nice.

There is a niggling problem though. It does seem rather mad to always have to wrap all our actions (verbs, if you like) into objects (nouns, if you still like). This can lead to stupid levels of object hierarchy, such as the AbstractSingletonProxyBeanFactoryFactory. The complexity this adds spoils our model of the real world because it turns out that actually 'life' is rather complicated and not easy to model at all. The tradeoffs we inevitably end up making come back to bite us before long, where we then either have the choice of breaking the model or breaking the world; technical, if not philosophical, debt results. Oh, and the reuse argument turned out to be a pipe-dream too.

Wouldn't it be better to pull the actions out of the building blocks into a more generic space where they can exists at peace without having to 'belong' to anything. This is of course the functional programming paradigm where simple, ideally generic, pieces of code can construct and transform the building blocks. Hell, they could even invent and construct brand new lego models by themselves without human intervention - macros anyone?

Of course, object vs functional is a false dichotomy - you don't necessarily have to choose one over the other. Objects can exist in a functional world (Clojure?) and functions can exists in an object world (Scala?). You just need to be aware of the dangers of modelling and the traps set by the universe when you do.

As a slight aside, OO was allegedly "discovered" when a couple of developers who were using a block structured language to write a simulation engine played around with moving the stack frame for a block to the heap, thus making the blocks long-lived. Objects were born!