The Software Craftsmanship North America (SCNA) 2012 conference was held at November 9 and 10 on the top floor of the AON Center in Chicago, IL.

Proud to be one of the few Europeans to attend this great conference, in this post I write about my personal highlights.

As this post is becoming pretty large I just have to skip over some talks. As the conference was amazing with great speakers, the talks I skip I still found very interesting.

Opening

Micah Martin -co-founder of 8th Light- opens the conference with a brief chat about software craftsmanship and a short introduction to the conference.

"This conference is not about specific technologies or programming languages. This conference is about attitude." Micah Martin

Cory Foy

When Code Cries: Listening to What Your Code is Saying

The honor of having the first talk of the conference was for Cory Foy. In this great talk he discussed code quality and communication.

A really interesting point that he made is that the quality of code is not something static. Code quality happens at the interaction point of the code base: when we try to understand it, modify it, or when the code is used by people. I.e. quality code is code that actually gets used and is a joy to work with. Code cries when it is not understood at the interaction point.

Cory made a comparison between the course of the Mississippi river and the course of design. We tend to feel the need to control things. We want to control the course of the Mississippi river even though it is natural for a river to change course over time. We just happen to like how it flows next to Orleans and we do anything we can to prevent it to naturally flow another course. We fear the natural change of the river.

Much in the same way we tend to control software design. The first time you use TDD to drive the design is quite fearful. After you get used to it and allow letting design flow more naturally, you learn that tests drive towards a design that is fully applicable to the situation on hand.

Further Cory explained the Foy-Z technique, a model that captures the way people learn to program in a simple yet elegant way. The model moves from cognitively undemanding (i.e. without clients, dead lines, etc) with context embedded to a cognitively demanding with context reduced, in a few steps.

With a few quotes from Christopher Alexander’s classic The Timeless Way of Building, this fantastic talk by Cory belongs to the best of the conference in my opinion.

Sarah Allen

Crafting Software Products

This talk is about product development. Sarah Allen told the story of one of her customers asking for a mobile app. Rather than coding up the MVP (Minimum Viable Product) she took a much different approach.

Together with her customer she examined the target audience of the mobile app and what they would expect of the app. Using ads to draw attention to prototypes (mainly static images and web pages) and various measurement techniques help to learn the target audience and their expectations of the app.

"Potential users should not be the target audience of an app, but those who will love and crave using the product" Sarah Allen

She referred to this as test-first product development: to start with a hypothesis, then test it, analyze the test results and learn from it. Then adapt to what you learned and reiterate, leading from a belief (the hypothesis) to knowledge (learned from the tests).

Adewale Oshineye

What Happens When Software Craftsmanship Meets User Experience?

Adewale Oshineye talked about usability of the tools and APIs developers use. Even though most tools are well designed, well made, very useful, they are not very usable.

Many tools developers use on a daily basis -like Git, Vim, Emacs- suffer usability. We use them anyway because they are the least worst tools out there.

Using the example of a glass door with the text ‘push’ on the one side and the text ‘pull’ on the other he makes the case to fix usability rather than document how to use it.

"A poor workman blames his tools" Adewale Oshineye

It’s very interesting because if anyone should be able to fix these problems in software it should be the people creating these products. Yet most APIs (and also tools) are designed from the perspective of its creator, not of its user.

Robert Martin

The Reasonable Expectations of Your CTO

Uncle Bob goes over the attitude of professionals. Simply stated, professional programmers:

• don’t ship shit
• know when to say no
• don’t lie about estimates
• are eager to learn
• invest time to improve their skills and work on their craft

The most reasonable thing for a CTO to expect of programmers is for them to behave professional.

In addition, a CTO can reasonably expect work to be done at a stable speed. Don’t start very fast and slow down along the way by making a mess. Also be fearless of the code you create; fearfulness is unacceptable. This means you can make changes to code easily without breaking it, which implies good design, clean code, and a healthy safety net. The reason we call this SOFTware is that it is easy to change.

Another thing is that QA should not find anything. And when they do the team should find out how that happened, learn from it, and prevent it to happen the next time.

"QA is not your debugger" Uncle Bob

Having read his book on professionalism - The Clean Coder - the attitude that can be expected of professionals was not new to me. Still talks from Robert Martin are always great. He’s a very experienced speaker, and you’ll learn something more about science every time.

Jen Myers

Developers Can’t Understand Design*
* and other completely mistaken design myths

Jen Myers tried to clear many of the common misconceptions about the work of a designer. Using a lot of quotes and great stories she made clear that designers do not just make things pretty, they make things work.

Using their own set of tools (like fonts, color theories, ui patterns, user testing, etc) designers make a product work for the intended audience. Therefore it is important for designers and developers to work together and have much interaction, unlike the common task handed over to a designer by a developer: “it works, please make it look pretty”.

She introduces the concept digital-native designer, who knows how to do visual and user experience design, and can implement it. For developers who want to learn about design, David Kadavy’s book Design for Hackers: Reverse Engineering Beauty could be good start.

Michael Feathers

Testing Revisited

In this wonderful talk Michael Feathers revisits testing. He starts with some sweetness.

Tests are sweet. They help us to think, precisely detect change, serve as documentation, and to get to done. Tests give us a hard line, 0 or 1.

Tests that serve more than one purpose may become harder to change. As with all code, a test should focus on one thing. This is where the SRP (Single Responsibility Principle) is applied in tests too.

He steps through some common problems with larger test suites.

Some teams phase that they are held hostage by their tests. Instead of supporting them to change the system these teams suffer from many failing tests if they try to make a change. This makes modifications to the system extremely hard.

Also tests can cause systems to increase heavily in build time. At first this does not seem like a big deal but as the system grows it becomes more and more time consuming to run all tests, to end with not running the tests anymore as it would take too long.

To the build time problem Michael proposes an interesting solution: to set a build budget. This forces the improvement of tests to not run out of the budget. It also makes a good case to do this to your customer.

Further he talks about deleting tests that are no longer of use or not really necessary. And to option of maintaining multiple suites and run only some of them.

Gary Bernhardt

Boundaries

Gary Bernhardt kicked off the second day of SCNA with his talk about boundaries and isolation.

Code is often tested in isolation by using stubs and mocks. While these serve isolation, they might be different from the real world. Using tools to check test doubles against a contract (such as rspec-fire, static typing, or integration tests) allows for writing tests that help catch these differences.

In this talk Gary shows a natural isolation of code: through value boundaries. In his presentation he uses examples from a Twitter client he wrote and talked about in a few DAS episodes. If you haven’t seen his screencasts, make sure to watch them soon, they are really awesome!

He separated the program into a functional core that contains the intelligence, surrounded by an imperative shell that brings in the dependencies.

After going through the following table of known paradigms, he introduces the name for this approach that combined functional and OO: Faux-O.

Functional code is much easier to test than imperative code as it has no side effects. You can test a function by its values, which are the natural boundaries of a function. Values also afford shifting process boundaries, of which the actor model is an example.

Sarah Gray

Visualizing Enumerable: Own Abstract Concepts Through Physicalization

Sarah talked about beginners, and how they require different kinds of help based on their background. She shared her stories of mentoring different beginners, and how often she’s reminded of the difficulties beginners face.

What help for example is it to point a beginner to the Ruby Docs? She used the example of the Enumerable select method. In this definition of select is so much context implied, that it would probably blows a beginners mind.

Sarah’s solution to this was to visualize these concepts by drawing pictures of what the lines of code actually do. She showed a picture explaining select with her select-cat, selecting balls by color and dropping everything else in the ocean.

Even though select-cat is not really friendly to the environment by dropping stuff in the ocean, she really uses a great way to visualize concepts for beginners.

Sarah also talked about how people learn in different ways, and that some require more visualization than others. I found her talk one of the most inspiring of the conference.

Kata Battles

On each day a kata battle was organized. This is a contest where both contestants would perform the Coin Changer kata live in front of all conference attendees. The winner was determined by the audience based on speed, style, creativity, etc.

The battles were a lot of fun to spectate, and I can only imagine also fun to perform (although under the huge pressure of the watching audience).

Fish bowl

On day one during lunch a fish bowl was organized.

Programmers rotate in as pair working on a software exercise. The exercise was the Clojure version of the Gilded Rose kata. The audience can observe, heckle, or help solve the problem.

Fish bowls are both fun and instructive.

Jeopardy

On day two during lunch a Jeopardy of software trivia was organized. The contestants were Cory Foy, Corey Haines, and Gary Bernhardt.

In conclusion

When I went to Chicago to attend SCNA I had high expectations of the conference. The schedule showed really experienced speakers, and some great entertainment. And SCNA managed to completely beat my expectations.

I find this an amazing conference, with very experienced speakers, great entertainment - I didn’t even mention the brewery trip, which was lots of fun! - and very nice, like-minded people.

I’ll try very hard to attend next year, so hope to see you there!