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
J. B. Rainsberger famously said that Integrated Tests are a
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
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
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—
filter are used
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
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
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.
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