Ben Scofield

It’s been a few days since we wrapped up Developer Day Austin, and I’m only now able to catch my breath – a few snowmageddon- and planning-related incidents combined to keep me pretty busy over the weekend and this week.

In a lot of ways, Austin reminded me of the very first Developer Day, back in March of last year. Some of the lessons in logisitics that we learned at that first event, in particular, were significantly reinforced by our experiences in Austin. Despite a few hiccups, however, the event as a whole went over well. I think we were able to bring together at least a few people who don’t often meet up – front-end developers and Rubyists, with a few Pythonists and others in the mix.

Our lineup of talks was front-end heavy this go-round, and that was interesting; I though Kyle Simpson and Alex Sexton did a great job bringing the JavaScript thunder, for instance, and I’m encourage to bring in more front-end talks at future events (especially because JavaScript is almost a lingua franca for web developers at this point). Unfortunately, I had to leave midway through the day (the aforementioned snowmageddon incident), so I missed Aaron Bedra, Eitan Suez, and Bruce Tate, each of whom I was excited to see.

And a few words about Austin… first, Austin is clearly Gowalla territory. Stepping off the plane, I was struck by how many featured spots there were, and it made bopping from place to place a lot of fun. Second, it was much colder than I expected. If I thought I underdressed for Boulder last year, it was nothing compared to the mismatch of expectations that Austin (and Dallas, on the way back) triggered.

Anyways, I think Austin provided a good start for the 2010 Developer Day season, and I’m really looking forward to the rest of the series – speaking of which, the next event is February 27th in Durham, NC, so if you’re anywhere nearby register today!

Raise your hand if you have a job description – a paragraph or eight that describe your role and responsibilities in your current position.Now, raise your hand if you have a specific set of goals for what you are supposed to accomplish today, this week, this month, and this quarter.

I’m betting that there’s little, if any, overlap between those two groups.

I used to be in the job description camp, and I was pretty effective. I built stuff, went to meetings, talked to people, got stuff done… I think I did a good job of matching the description. For the last eight months or so, however, I’ve been in the second camp. In lieu of a formal job description, I have specific, measurable goals to accomplish in any given time period. As a result, I can tell you exactly how I’m doing at any given point, and where I need to focus my efforts to get more done.

For freelancers, of course, this is probably an obvious change – when you work for (and substantially by) yourself, your job description is “get everything done,” which means you have to fall back on goals. For employees, however, changing your mindset from a vague prose passage to a set of concrete goals can be a massive shift. It can dramatically improve your effectiveness at your current job – or it could show that you should’ve been doing something different all along.

I had a thought the other day… I wonder if the demise of correspondence via letters has resulted in a reduction in significant thought. Here’s the idea:

When long-form letter writing was the predominant means of long-distance communication, you had some astounding exchanges (Descartes’ correspondence with pretty much everyone, for instance). Many great thinkers first detailed their theories in these long letters, and I wonder if the form itself made that more likely. Think about it – when you’re corresponding via letter, longer messages are more efficient (whereas the opposite is true today, with email, IM, and tweets). Longer messages mean more time writing, and more time writing means more time thinking through what you want to say. As a result, then, writing long letters may have helped people think through their ideas more fully before making them public.

If that’s the case, then it very well might be the case that today’s preponderance of short-form communication makes it much less likely that anyone will release a complex idea fully-formed – but the greater frequency (and reach) of their interactions with other people may overcome that deficit. Could it be that letter-writing was waterfall, and email, IM, and Twitter are agile?

(And might this post play into that precise analogy, being far from presenting a fully-formed theory itself?)

So, after some difficulties getting the planes to fly on time, I finally made it home from CodeMash late last night. Despite only being there for a short time (and being intensely jealous of everyone who was able to stay for the full event), I had a great time.

I did notice a couple of differences between CodeMash and the Ruby/open source conferences I normally attend, however. First, the gender balance was, while still skewed, was much closer than I’m used to. I remember hearing somewhere that there were more women in enterprise computing (.Net and Java) than in the more fringe technologies, and I guess I’ve got anecdotal evidence to back that up, now.

Also, the sponsorship atmosphere was very different – in fact, it felt more like the Startup Crawl than it did the Expo Hall at RailsConf. Sponsor booths had video games, coding problems, and a ton of giveaways (both raffles and freebies), and their staff were a bit more assertive.

My talk (an updated version of the one I gave at RubyConf) went over well, I think – no ratings on SpeakerRate yet, but (like all technical conferences) there were substantial problems with the wifi, so I’m hoping that people will rate it once they return home. I did fail in one significant way, however: I didn’t consider my audience as carefully as I should have. The needs of an audience of .Net, Java, and related technologists are somewhat different than those of a room full of Rubyists. I got a question on Neo4j’s licensing, for instance, that hasn’t come up in any of the half-dozen or more times I’ve talked about it previously.

I don’t think that this problem affected the presentation itself, but it’s certainly something I should have done for the question period.

The first RubyConf talk I gave was entitled Cleanliness Is Next to Domain-Specificity; in it, I spoke about DSLs, and gave an example of how you might want to create one (I also spent some time talking about regional variation in Little Bunny Foo Foo, but that’s neither here nor there). At the time, I said that the best way to design a DSL was to write out what you wanted it to look like, and then write the code that made that functional.

I’ve since become convinced that this process is in fact the best way to design any code, not just DSLs. API? Write out how you want to call it, then write the code that responds to those calls. Routing in a web app? Write out the URLs you want people to hit, then create the code and routes that will make those work. A web page? Design the page, build it out into HTML, and then write the code that makes it live. Each of these is an example of design-first development.

You may be wondering if I’m abandoning the lean/agile fold for waterfall with this idea. Happily, I’m not. If you think about it, this is how TDD (or BDD) works: you write a test or spec that runs some code (in the process, designing how you’ll interact with the code), and then you write the code that makes it pass. The sort of design I’m talking out isn’t fossilized in spec documents, but is actually executable when you finish writing the code to make it work.

The key to all of this is realizing that design happens at a number of different levels. In the examples above, I described design the level of writing code (DSL), of integrating with systems (API), of browser interaction (routing), and of user interface (web page).

I think that more and more people are realizing the power of this approach at various levels, but I’m convinced that recognizing each of those levels as an instance of using design-first development may provide better insights into the process overall.