Many people who explain agile software development often discuss project and planning practices, but hardly mention the development phase. In this insightful video, renowned software architect Neal Ford drills into the real details of agile engineering practices from a pure development perspective. Discover the development and design practices that make the agile approach work, the pros and cons of feedback mechanisms, and a host of related topics.
I was asked to do one of the mid-week morning keynotes at RailsConf in 2010. I suspect I was a replacement for someone who dropped out because I was asked only about 6 weeks out. That’s fine with me - I’ll gladly jump at the chance to keynote one of my favorite conferences!
But now I had to come up with a topic, and I didn’t want it to be the run-of-the-mill “Enterprise Software Development Isn’t So Bad” kind of talk. I solicited several mailing lists of Really Smart Guys, and my friend (and the author of the preface to The Productive Programmer) suggested something about the effect of constraint on creativity. I had also had some thoughts along those lines, and started thinking about the subject. Because of the subject matter, I decided to not touch Keynote until 24 hours before the talk, spending the rest of the time thinking and designing what it should be. That’s what I did, but the outcome was not what I (or anyone) expected. While I kept trying to keep the subject on Creativity and Constraint, the subject of art kept intruding, and eventually took over. You’ll have to watch it to see how I finally resolved the two subjects.
As part of my work on the Presentation Patterns book, I created a super-detailed annotated version of this talk, explaining in gory detail all the design decisions I made & why. If you really want to understand what I was thinking about as I authored & presented this keynote, it’s here in full glory. You should watch it first, then look at the annotated slide deck, which is every slide including all the transitions & animations and my comments.
Download the annotated keynote here.
Like any form of art, you can infuse a presentation with a lot of sophisticated, mostly hidden little features (foreshadowing, symbolism, advocacy, etc). Most of the audience probably won’t pick up on it directly. For example, you can watch the movie The Sixth Sense as just a thriller with a very surprising ending. But you can also watch it as a brilliant bifurcated plot, with tons of color symbolism. For example, watch out for the color red, which suffuses the whole movie. At first, red seems to show up in 2 circumstances: when the boy sees ghosts and when we’re looking at scenes about his doctor. Of course, by the end you realize that there is only 1 trigger for the red after all. You would never notice that the first time through the movie. However, it is my contention that those elements, even if they are subtlety invisible, make the movie “seem” more solid, more sophisticated, more artistic. And, of course, you can go back and identify those things, but it shouldn’t diminish your enjoyment of the movie itself. It is those subtle features that help differentiate between things that are art and things that are merely entertainment.
I think that, if have a presentation that includes all these artistic elements, it seems more complete somehow than one that doesn’t. This is my justification for building this really elaborate keynote for RailsConf, which includes tons of stuff that I’m sure no one noticed and will never go back to notice (I don’t for a moment think my keynote is as entertaining or compelling as The Sixth Sense).
I’ve wanted to do a keynote at RailsConf for a while because it’s one of my favorite conferences. In 2010, they turned down all my regular talk proposals (not too surprising: they have a huge number of submissions, and they tend to be pretty cutting edge at this conference). However, about 6 weeks before the conference, they contacted me about doing a 30 minute keynote (one of their keynoters had dropped out). I agreed.
I solicited some advice from several mailing lists, and David Bock ended up with a good suggestion that resonated with some stuff I had already been thinking: what is the effect of constraint on creativity?
Based on the topic, I resolved to not touch the presentation tool until the day before, to keep myself from committing to a visual idea too early. But I thought about this a lot over the intervening time, created mind maps, found some elements I knew would be there (the quote at the end I discovered very early & knew it would be the ending).
When I started putting all my thoughts together, though, I found that the combination of subjects I had assembled kept “pushing” me towards another theme, which I ended up going with. About 2 days before the talk, I decided that I would use the Creativity & Constraint theme to act as a path to lead to the real theme, which is a very broad, very abstract challenge to the crowd to start thinking about writing software in a different way, that the code itself that we use as a medium might be an interesting artistic medium.
My keynote for 2009 was entitled Ancient Philosophers & Blowhard Jamborees. In it, as in many of my keynotes, I try to dissect the ills of the software industry from a developer’s standpoint.
The conceit of this talk is that we always think the interesting stuff is in the future, that technology always marches forward. Yet this causes us to ignore important lessons from the past. The ancient philosophers had a lot to say about how to build software, and we’d better start listening, or all the jobs are going to other places where they aren’t so silly.
This keynote is a classic example of a 3-act Narrative Arc. The first part sets the stage, using the Ancient Philosophers to supply a framework that allowed me to talk about the topics I wanted to talk about. The philosophers were carefully chosen to make sure they fit the overall narrative. I’m introducing the players and situations here.
The second act explains a variety of disfunction in the enterprise development world (easily identified because I numbered them). The end of the second act is the “Do you want fries with that?” slide. Whenever I give this talk, you can hear a pin drop at this point; I’ve bummed everyone out to the point of suicide.
The 3rd act is all about how we can change to prevent this dire outcome (also numbered, a magic 10 items), and ends with an inspirational quote.
This keynote also demonstrates the metronomic mind breaks pattern: the humor is carefully planned and distributed throughout.
I’ve done a variety of videos at conferences that InfoQ taped. These are hour-long versions of 90 minute talks, based on the constraints of the conferences.
I shows what ThoughtWorks learned from scaling Rails development: infrastructure, testing, messaging, optimization, performance.
In this presentation recorded during QCon SF 2008, I show 10 ways to write better code. This is practical advice for developers, but application architects can benefit from it too.
This is a talk I did at JAOO in 2007 talk talks about the very early days of Mingle, Thoughtworks Studios’ project management software. Mingle is written using JRuby - I explain the experience of building a product on JRuby, solutions to problems, and future plans for using JRuby in Mingle. Don’t consider any of this current, but does provide some insight into the early days of pushing JRuby as a platform for desktop deployment (which is still the case).
