SCNA 2011 Conference Report

Question

Last week I attended Software Craftsmanship North America 2011 (thanks again, Stack Exchange!).

I spoke to a number of people about Stack Exchange in general and Programmers in particular, and handed out some stickers and a few of my shiny and new moderator business cards. I don't know if this is going to translate into many new users for us, but the word's now out there. :)

There's a lot to go through, so it's going to take me a bit to get it all out there, but I'm going to post session summaries here as answers to this question. They'll also be cross-posted to my blog.

I had grand plans to keep up with Programmers during the conference, but it really moved way too quickly to do any meaningful knowledge sharing then. Between my blog series and searching for existing related questions to add an answer to, I hope to bring back some value to the community here.

All in all, I had a blast at the conference. If the Stack Exchange sponsorship grant still runs next year, I highly recommend applying for it. The sponsorship program is available to regular community users, not just moderators, so for that matter... if you know of a relevant conference you'd like to attend and help promote Programmers at, please make a meta post and tell us all about it!

In the meantime... enjoy the summaries here. I hope you'll find them interesting. If this is your first time in this question thread, sorting the answers by oldest is recommended.

Answer 1

Part 0: Introduction

_{Originally posted at http://annalear.ca/2011/11/26/scna-2011-part-0-introduction/. Reposted here with minor edits.}

SCNA is the exact opposite of a vendor-focused conference. It is a conference full of developers who actively want to be there. It's amazing how much difference that makes.

The conference runs for two days and both days are pretty full of stuff to do. You're on your own in the evenings, but I haven't found that to be a problem — talking to a few people during the day more or less guarantees having company for dinner.

This year there were two tracks of talks with an unfortunate overlap between speakers. It wasn't a problem for me for the most part, but I did have to leave a couple talks before they finished in order to get to the next one on time. There was also an "open space" room set up for hanging out, hacking on random things, and ad hoc pairing.

Despite the name, it wasn't a traditional open space, well, space. Typically you'd see a board and some sticky notes for people to propose their own mini-sessions. This time, there were a few smaller groups getting together, but I found it difficult to figure out if there was anything special going on at a given time.

Many of the talks weren't announced ahead of time, which made choosing ones to attend a bit odd. Still, a little mystery never hurt anyone, and I attended the following sessions:

• The opening keynote by Corey Haines in which he talked about developers: where we came from, where we're going, and whether or not we are about to repeat some of the mistakes of the past.
• A demonstration of functional programming style by Michael Feathers.
• An interesting look at the evolution of programming languages by Gary Bernhardt.
• The apprenticeship panel that gathered several prominent developers and company owners to talk about why they take on apprentices and what they're looking for when they do.
• "Architecture: The Lost Years" by Robert "Uncle Bob" Martin.
• A demonstration of the Roman Numerals kata in Ruby by Jim Weirich.
• A discussion of parallels between learning and practicing a musical instrument vs practicing programming by David Chelimsky.
• A critical look at software development education and propagation of popular methodologies by Zed Shaw.
• The closing keynote by Chad Fowler in which he talked about the values held by passionate developers.

I'll post my summaries of other sessions here as well where possible. If anything's unclear or you have questions or comments, feel free to leave comments or catch me in chat.

Answer 2

Part 1: Opening Keynote

_{Cross-posted at http://annalear.ca/2011/12/09/scna-2011-part-1-opening-keynote/}

SCNA 2011 opened with a keynote by Corey Haines. He talked about the past and the future of software development as a profession, the trends that are emerging in the current economic climate and how that affects us as professional developers.

Where We Came From

Back in the 90s the tech sector virtually exploded and a lot of people got into software development with the help of all those "Learn X in 24 hours" books. This was great, but it did result in a lot of people quickly learning how to code and getting jobs without learning much about the profession overall.

That gave the impression that it was very easy to become a programmer. With the increasing numbers of new developers, there weren't enough older, more experienced developers to train them. At the same time, companies employing developers at the time (and even now) just want results. They trust that the people they hire know what they're doing, so it is rather up to us to self-organize and recognize that it's relatively easy to learn how to program but there's a difference between being able to write some code and developing maintainable software.

Where We Are Today

The tech bubble of the 90s is long gone and since then the economy has come down again. A lot of people got laid off from their jobs and either out of opportunity or necessity are starting up their own small businesses. Those businesses often need software, so developers are once again in demand. So are we doomed to repeat the mistakes of the past?

Well, maybe. But it doesn't have to be that way.

What Next?

More and more trends are emerging that are promoting software development as a craft, something that needs to be practiced and learned and cannot be taught with a book and 24 hours.

Apprenticeship programs are starting up in various places and many companies are more open to the idea of hiring apprentices and having some of their developers spend time on training. There are also online organizations like Girl Develop It.

So, that's all well and good, but why do we care? Didn't the tech boom work out in the end? Aren't we better for it?

Why Bother?

It turns out that software development is not easy. In fact, it's quite hard. But companies are starting to wake up to that fact. As software becomes more and more ubiquitous every day, it's easy to see good, maintainable applications and discover the badly written ones by comparison.

For those of us who spend time practicing and learning new techniques, having untrained developers enter the workforce can be actively harmful.

So What Can One Person Do?

• Learn as much as possible
• Reclaim professional values:
  • build communities, connect with others
  • add value, do things that matter
• Practice the craft
  • code retreats, coding dojos
  • work on personal projects
  • attend interesting conferences
• Be awesome.

Answer 3

Part 2: Michael Feathers, "The Readability Gulf"

_{Originally posted at http://annalear.ca/2011/12/27/scna-2011-part-2-michael-feathers-the-readability-gulf/.}

The second session of the first day was by Michael Feathers giving a demo of using functional approaches to different problems.

I took two main lessons out of it:

1. "Clever code" is relative.
2. Functional programming can help establish a common base of understanding that doesn't vary from one problem domain to another.

"Clever code" is something that's often looked down upon because it can make it more difficult for multiple developers to maintain an application and read its code. But what is "clever", exactly? Michael Feathers made the point that anything that's unfamiliar to us will at first look as strange and weird. But if we take the time to learn new functions and patterns, they will quickly become familiar and comfortable instead of too clever and complicated.

Another way to mitigate the gap between unfamiliar and comfortable is to use common functions. Functional programming is a good example of that: it is more about manipulating data without worrying about setting up abstractions to model it first. Functions built into a functional language aren’t trying to represent the domain of the problem. Instead, they simply perform common operations that do the same thing regardless of what kind of problem they're applied to.

For example, the zip function is the same in Ruby, Python, Scala, Haskell, and other languages. This means that you can learn how it works once and if you find yourself working in another language or another domain, you can easily apply it there.

The same holds true for design patterns and, to an extent, frameworks.

Establishing a common base of understanding is important for ensuring that we write the best code possible. Sometimes this requires compromises to favour readability over efficiency or style, but other times we're better off using some clever code on the assumption that we and our fellow developers will learn how it works and become better for it.

Answer 4

Part 3: Gary Bernhardt, "Expansion and Contraction"

_{Originally posted at http://annalear.ca/2012/01/10/scna-2011-part-3-gary-bernhardt-expansion-and-contraction/}

Gary Bernhardt took the stage to talk about the evolution of programming languages and technologies. He talked about the fact that languages and technologies evolve in waves: first there’s a wave of expansion where a new language comes along and increases the number of things we can do, and it is followed by a contraction that reduces the number of things we can do but also removes a lot of confusion and therefore enables us to deliver more reliable software with the new toolset.

So, expansion increases capability – our power to express an idea. Over time abundant resources and confusion drive change and we see a contraction that removes 5% of the capability and 85% of the confusion to enhance suitability – the power to deliver reliable software that works.

Many expansions are initially dismissed by the developer community. For example, looking back at Djikstra’s proposal for structured programming, it was met with the following review:

Structured programming is a nice academic exercise, which works well for small examples, but I doubt that any real-world program will ever be written in such a style.

The relational model was met with similar criticism and the same quote can be paraphrased and applied almost universally to new technologies coming out today. Instead of focusing on how something can’t possibly be workable, we should consider what larger purpose it may be serving: either by improving capability or suitability.

Here are some examples from history:

• 1957: Fortran increases capability vs Assembly.
• 1968: Structured programming increases suitability vs Fortran.
• 1970: Relational model comes out as more suitable vs flat files.
• 1985: C++ is more capable vs C by adding object-oriented concepts.
• 1995: Java is more suitable vs C++ by removing some of the complexity and introducing automatic memory management.
• 2004: Rails extends the capability vs existing ways to develop web applications.

Rails displays a culture of capability. The focus is on new gems and new features all the time and when something breaks, it’s easier to just move on to the new working thing than fix the broken one.

Gary made a point that capable systems generate a lot of activity (for example, the gem explosion in Rails), but then a contraction into more suitable tools creates suitable systems where the real progress happens. He described the difference between activity and progress as a developer who commits code lots of times a day but doesn’t necessarily produce a lot of value. That developer is certainly active but may not be making much progress.

So what happens after Rails? Gary suggested that there’s frustration building in the developer community and it’s likely going to lead to a contraction step. Up next are the functional revolution and outside-in top-down London style test-driven development. Which are, of course, impossible since they are nice academic exercises, which work well for small examples, but no real-world program would ever be written in such styles.