austin kleon

Steal Like an Artist

Peter Cripps creativity , , , , ,

David Bowie is having something of a resurgence this year. Not only has he released a critically acclaimed new album, The Next Day, there is also an exhibition of the artefacts from his long career at the Victoria & Albert museum in London. These includes handwritten lyrics, original costumes, fashion, photography, film, music videos, set designs and Bowie’s own instruments.

David Bowie was a collector. Not only did he collect, he also stole. As he said in a Playboy interview back in 1976:

The only art I’ll ever study is stuff that I can steal from.

He even steals from himself, check out the cover of his new album to see what I mean.

Austin Kleon has written a whole book on this topic, Steal Like an Artist, in which he makes the case that nothing is original and that nine out of ten times when someone says that something is new, it’s just that they don’t know the the original sources involved. Kleon goes on to say:

What a good artist understands is that nothing comes from nowhere. All creative work builds on what came before. Nothing is completely original.

So what on earth has this got to do with software architecture?

Eighteen years ago one of the all time great IT books was published. Design Patterns – Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides introduced the idea of patterns, originally a construct used by the building architect Christopher Alexander,  to the IT world at large. As the authors say in the introduction to their book:

One thing expert designers know not to do is solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is part of what makes them experts.

So expert designers ‘steal’ work they have already used before. The idea of the Design Patterns book was to publish patterns that others had found to work for them so they could be reused (or stolen). The patterns in Design Patterns were small design elements that could be used when building object-oriented software. Although they included code samples, they were not directly reusable without adaptation, not to mention coding, in a chosen programming language.

Fast forward eighteen years and the concept of patterns is alive and well but has reached a new level of abstraction and therefore reuse. Expert Integrated Systems like IBM’s PureApplication SystemTM use patterns to provide fast, high-quality deployments of sophisticated environments that enable enterprises to get new business applications up and running as quickly as possible. Whereas the design patterns from the book by Gamma et al were design elements that could be used to craft complete programs the PureApplication System patterns are collections of virtual images that form a a complete system. For example, the Business Process Management (BPM) pattern includes an HTTP server, a clustered pair of BPM servers, a cluster administration server, and a database server. When an administrator deploys this pattern, all the inter-connected parts are created and ready to run together. Time to deploy such systems is reduced from days or even, in some cases, weeks to just hours.

Some may say that the creation and proliferation of such patterns is another insidious step to the deskilling of our profession. If all it takes to deploy a complex BPM system is just a few mouse clicks then where does that leave those who once had to design such systems from scratch?

Going back to our art stealing analogy, a good artist does not just steal the work of others and pass it off as their own (at least most of them don’t) rather, they use the ideas contained in that work and build on them to create something new and unique (or at least different). Rather than having to create new stuff from scratch they adopt the ideas that others have come up with then adapt them to make their own creations. These creations themselves can then be used by others and further adapted thus the whole thing becomes a sort of virtuous circle:Adopt Adapt

A good architect, just like a good artist, should not fear patterns but should embrace them and know that they free him up to focus on creating something that is new and of real (business) value. Building on the good work that others have done before us is something we should all be encouraged to do more of. As Salvador Dalis said:

Those who do not want to imitate anything, produce nothing.

Choosing What to Leave Out

Peter Cripps architecture, creativity ,

In his book Steal Like an Artist, Austin Kleon makes this insightful statement:

In this age of information abundance and overload, those who get ahead will be the folks who figure out what to leave out, so they can concentrate on what’s really important to them. Nothing is more paralyzing than the idea of limitless possibilities. The idea that you can do anything is absolutely terrifying.

This resonates nicely with another article here on frugal engineering or “designing more with less”. In this article the authors (Nirmalya Kumar and Phanish Puranam) discuss how innovation is meeting the needs of the Indian marketplace, where consumers are both demanding as well as budget constrained and how “the beauty of the Indian market is that it pushes you in a corner…it demands everything in the world, but cheaper and smaller.” This article also talks about “defeaturing” or “feature rationalization”, or “ditching the junk DNA” that tends to accumulate in products over time.

As an example of this the most popular mobile phone in India (and in fact, at one point, the bestselling consumer electronics device in the world) is the Nokia 1100. The reason for this device’s popularity? Its stripped down functionality (ability to store multiple contact lists so it can be used by many users, ability to enter a price limit for a call and built-in flashlight, radio and alarm) and low price point make it an invaluable tool for life in poor and underdeveloped economies such as rural India and South America.

For a software architect wishing to make decisions about what components to build a system from there can often be a bewildering set of choices. Not only do several vendors offer solutions that will address the needs there are often many ways of doing the same thing, usually requiring the use of multiple, overlapping products from different vendors. All of this adds to the complexity of the final solution and can end up in a system that is both hard to maintain as well as difficult, if not impossible, to extend and enrich.

Going back to Austin Kleon’s assertion above, the trick is to figure out what to leave out, just focusing on what is really important to the use of the system. In my experience this usually means that version 1.0 of anything is rarely going to be right and it’s not until version 2.0+ that the fog of complexity gradually begins to lift allowing what really matters to shine through. Remember that one of my suggested architecture social objects is the Change Case. This is a good place to put those features of little immediate value, allowing you to come back at a later date and think about whether they are still needed. My guess is you will be surprised at how often the need for such features has passed.