RailsConf Europe - Dave Thomas Keynote
September 18th, 2007
Last night Dave Thomas kicked off RailsConf Europe with something different. Rather than evangelize Rails or talk up the lastest/next big thing, Dave set the tone for the conference by stripping back it to the core philosophy’s of software development and created a grand analogy.
Rails and Art
Dave’s well spoken, in a mid-atlantic accent, and funny keynote concentrated on the definition of software development as art or engineering. By making multiple analogies to software development to famous works of art and the methods of artists of history, Dave was trying to create a philosophy behind not just good software but truely great, beautiful software. He looked at four main things.
Starting
Just as the artist is faced with a blank canvas, the developer is faced with a blank IDE. But an artist doesn’t jump right in and start to create the masterpiece. Instead the use sketching and work in other mediums to deduce how a masterpiece will evolve. Consequently the developer should work in other mediums, or index cards or lego. They could use prototyping of small complex areas, exploratory testing to validate understanding and creating a “tracer bullet”, a complete end-to-end system but without any details, later they can fill in the details or just start over.
be prepared to throw 10 away, because the 11th will be sweet.
Stopping
In a grand mosiac such as the sistine chapel, its hard to be close to the detail when the work is so large. So Dave talks about about how to chapel is broken into panels, all unique “loosely coupled” but come together to tell a long story. Hence developers can set boundaries not just in function (modularisation) but in time then honouring those boundaries. Short distinct length development times and if your feature is only half finished at the end. Stop and be prepared to throw it out and do it again in the next iteration.
Satisfy the customer
Pictures versus portraits. An artist painting a portrait tries to look inside someone and find a way to express it, even if its abstract its still a representation. The developer needs to find a way to satisfy the underlying requirement.
Be in the habit of not listening to the client.
But to do so a developer needs to look beyond the surface, be appropriate, work with client and get to know them. Dave used two great anecdotes, the NASA space pen (the real story) and the driving license camera as two conflicting stories. Where some clients don’t realize they have the need for a technology solution but some clients don’t need high technology, listen to what they really need.
Why
There is art in engineering and engineering in art.
Be an artist. Create something great. Create something beautiful.
Sign your work. No more anonymous applications
My review
I really liked Dave Thomas’s keynote, he is a fine speaker, smart and inspirational. Talking to a few people afterwards there was a little “Yeah but that’s what we are like…” but for two things..
- Not all developers are the artists they think they are.
- The majority of development teams don’t know this at all, they are stuck in the production mentatility of ‘lines of code produced per hour’ and ‘man-days effort’
I think Dave’s keynote would have gone down best with the non-technicals, the managers, the CTO’s, the executives. Maybe then they can treat the developers a bit better than code generation machines and like real artisans.
Stuart Eccles
1 Response to “RailsConf Europe - Dave Thomas Keynote”
Sorry, comments are closed for this article.
September 21st, 2007 at 03:57 PM
I don’t think anyone who’s ever sat through one of my presentations would classify me amongst the non-technicals, but I definitely grokked what Dave was saying. What gives me such a charge at these Ruby/Rails-oriented events is that we are as a community as concerned about the aesthetics of what we do, and I think this keynote struck the perfect tone for why so many of us have moved from inferior technologies.
Similar arguments can be found in Paul Graham’s “Painters and Hackers”, a book I’d recommend to any of your readers who’ve yet to meet it, and it’s interesting to see how often the Lisp and Ruby mindsets end up back at the same point – even though the tools themselves seem very different.
In fact Matz’s principle of least surprise is nothing more nor less than an acceptance that code should conform to aesthetic principles that reflect the nature of computation, rather than the other way around. Now if that’s not the core of being a true artist, what is?