SoCraTes 2013

Note: This is an article about SoCraTes, an unconference in Germany. It is not about SoCraTes UK (wich is based on SoCraTes), which I’m helping to organise as part of the London Software Craftsmanship Community, although I hope to be able to write a similar article about that unconference very soon.

SoCraTes 2013 was a lot of fun, and the discussions, just like last year, were top-notch. There are a few topics that were covered that I want to highlight as food for thought.

Have we solved testing yet?

The short answer is “nope”. As an industry we’ve put a lot of effort into figuring out how to best test our code, but we’re still nowhere near agreeing.

J. B. Rainsberger famously said that Integrated Tests are a Scam, but the alternatives are unclear. We need some integrated tests, right? Maybe we can knock out more and more until we’re left with just a few, but having none seems very foolish indeed. Uncle Bob recently gave a talk in London on the value of acceptance testing, in which he pointed out you can test your UI and your domain logic separately by dividing up your application properly. Internal APIs play a big part in this—if you can stabilise internal communication channels, you can stub or mock them out.

Nicole gave a talk on a project which used specification by example to determine the system requirements. This smelled a lot to me like up-front design, and it was good to be reminded that no matter what the Agilerati say, it’s not necessarily a bad thing. Quite often it’s necessary to write a bunch of high-level test cases (“specifications”, in this case) before you can even start building a product. This talk incidentally also highlighted the value of converting integrated tests into unit tests, as she demonstrated how the initial specification had hundreds of test cases, and as they refactored it towards single responsibilities, the number went down by orders of magnitude.

Why are we reverting to technologies from the last millenium?

It’s becoming more and more obvious that people are fed up of their IDEs, and nothing demonstrated this more than a session on vim tips. Possibly the most complicated editor still in circulation, it’s well-known for being impossible to use in part because every person has a different configuration and set of keyboard bindings. This is in part due to the growing popularity of dynamic programming languages such as Ruby or Clojure, for which an IDE is practically useless anyway.

Speaking of Clojure, the rise of functional programming is fascinating. Everyone seems to be jumping ship to languages or libraries with a functional bent. Even C++11 has lambdas and higher-order functions, and Java will be getting them next year in version 8. That said, most developers dipping their toes in the water tend to write very imperative code even in these functional languages—map and filter are used sparingly, reduce is avoided and monads in general are out of the question. People are very curious about the concepts, but it’s still very new, and the sessions focusing on the practical side of the topic reflected that, with a lot of teaching by Irene, Johannes and Nicole. I imagine there’s a few things driving the shift to functional, including curiosity and the desire to do more in fewer lines of code (which is great: fewer lines = fewer bugs), and the need to keep up with advances in hardware capabilities, most of which are currently driving towards parallel architectures. In short, performance.

This need for more speed also explains the push towards asynchronous programming, using actors, messaging and continuation-passing style among other mechanisms to stop our applications blocking at all costs. Sergey explained how they all work at a high level, explaining the pros and cons of each. With all of these come a bit of added complexity in your design to start, but I think this might just be because of my mindset. If the entire application or module is designed with asynchronous concepts from the start, I expect it will actually lead to more decoupling than is common in traditional enterprise architectures.

Back in the world of functional programming, Kore kicked off a discussion on monads with a twist: he wanted to talk about how they can actually improve your object-oriented design. I think the reason really boils down to a separation of concerns: when you separate your transformations from your domain, writing your operations can become quite easy. For many applications, modelling behaviour as a series of simple steps is very valuable, and monadic transformations allow you to do this while still maintaining the flexibility that comes from nesting functions.

All this comes at a cost though, and René and Hans Martin pointed out that this sort of thing is very hard to do in the embedded space, when memory is at a premium. It’ll be interesting to see how developers close to the metal react to paradigm shifts in the next ten years or so.

Will programming ever change?

All that said, are things really changing at all? Bret Victor’s recent talk, The Future of Programming, was a talking point at the conference, asking the important question: have we really changed at all in forty years? Aren’t we dreaming of the same things we dreamt up in the seventies?

I think we’re getting somewhere. Sure, text is still the dominant medium in software development (because nothing is as precise, portable or non-proprietary) and we still look at two-dimensional screens, but we’re doing things never imagined in way back then. I was reminded of a scene in 2001: A Space Odyssey where one of the characters makes a video call to his kids from space. He used a coin-operated machine in a booth. I don’t think even the visionary Stanley Kubrick imagined a device as simple and elegant as the iPhone, allowing you to make audio and video calls from practically anywhere you want for free.

We still don’t have flying cars, but things are getting bigger, brighter and better. We can thank the hardware experts for this. Most advances in software are only possible because of Moore’s Law and the ever-increasing bandwidth to our homes.

This also brings us back to functional programming. In the ’60s, LISP was a research programming language. Now, it’s edging closer and closer to mainstream. We don’t have to worry about the performance of individual instructions any more—we can concentrate on designing things well. Only by raising the level of abstraction have we been able to power the enterprises across the globe.

How do we bring software craftsmanship to cowboys?

It wouldn’t be a software craftsmanship conference without people talking about spreading the love. René and I chaired a discussion on convincing others to build things The Right Way™.

The problem: everyone else is writing terrible code and you don’t have the power, the inclination or the time to fix it.

The solution: find one person who’s interested in what you have to say. Latch onto them like a limpet and don’t stop feeding them with information until they’re truly converted. Then repeat with a second person. Once there’s three of you, people will start to take notice. People are more willing to take account of information that comes from multiple sources, so get everyone reading blogs and books too.

How do you get the first person? With stealth. Avoid terms that are linked to the XP, agile and software craftsmanship movements. Make up your own that don’t have politics and dogma associated with them. Talk about “training workshops”, not “katas” or “code retreats”.

You can also pair like a ninja. Go to someone and ask for help on a problem you’re trying to solve. Offer him or her a seat, and then later the keyboard and mouse. Alternatively, when someone comes to rant at you, ask if you can see their code, then pull up a chair. Voila! Instant pairing without any hassle.

One issue that was raised by a number of people working in more standard environments is the idea of code ownership. This needs to be destroyed for you to have a chance of bringing good practices to an entire team. While one person owns a module or project, it’s unsalvageable—you can’t make changes if you have no control. The idea that the company or the team owns the code is a really important thing to push here.

It takes work, but it’s worth it.

Conclusion

A++++++++++++. Would attend again.

The attendees from London liked SoCraTes so much last year that this year, we’re cheating. We’re running our own. SoCraTes UK is in just a few weeks and at the time of writing, there are just three tickets left. It’s going to be amazing. I can’t wait to meet everybody and discuss the future of our industry and our craft.