I was at the Software Practice Advancement conference (SPA) last week, here are a few of my thoughts from some of the sessions I attended:
The Real-time Web
Phil and I presented Kwwika in the context of realtime web in general, and then walked people through subscribing and publishing data to the service. The feedback was very positive – people said that the exercises were pitched just right, and one attendee even said that he’d like to run colleagues at his work through the same set of exercises. One of the attendees was from pusherapp, a company doing something quite similar.
Get Clojure!
An overview of the Clojure programming language, which is essentially LISP for the JVM. An interesting language, together with its own style of doing things. Its templating abilities make it very powerful for developing internal domain specific languages.
Complexity and the Human Dimension
A talk by Maurice Mitchel, who is a reader in Architecture at London Metropolitan University. The idea was for him to describe the work he does in the slums in India, at the centre for alternative technology, etc, and for us to draw our own conclusions about its relevance to software design. He emphasised the importance of boundaries (which would be interface boundaries in software), of understanding the problem space before trying to build a solution, of putting that little bit of extra effort into making a solution that can survive. He believes strongly in each separate component having its own identity and coherence.
Test-Driven Development as if You Meant It
The core point of this session was that often, even when we’re doing test driven development, we start with a solution in our minds, then write the tests to test this solution, then write the code for the solution. In doing so, we haven’t let the testing influence the design at all. We were set the challenge of writing tests without assuming anything at all about the implementation that would result from the tests, which was very difficult. I came to the conclusion that the only way to do it is that the first few tests you write should be descriptions of the problem rather than the solution.
Wolfpack Programming
Interested in how cloud computing will change the process of creating software, the guys at Cincom have come up with the concept of wolfpack programming in which a pack of developers work on a problem on a live code base simultaneously. To make this work, they develop the metaphor of the wolfpack, having the pack be in different modes (hunting, running, worrying, etc), having designated ‘alphas’ who decide the current mode etc. I found the experience very interesting, but the development environment they used was still in early stages, and the language was smalltalk, with which I’m not very familiar, so because of peripheral issues it was difficult to really evaluate the value of the metaphor.
An Introduction to Scala for Java Developers
Scala is an interesting language that looks to merge many of the insights from academic functional languages like Haskell and the broad understanding and use of Java. It’s got a more expressive type system, and supports lots of changes to reduce the amount of boilerplate code that has to be written compared to java. In can be deployed in normal JVMs, and is being used in a number of commercial settings, such as Twitter.
Being Lazy
Focussed on the different programming techniques that lazy evaluation makes possible. This session was run by the guys at Barcap who are using Haskell to describe deriviatives. Since very few languages support lazy evaluation without ugly hacks, this session was largely about the main one that does – Haskell.
Agile Product development in the games Industry
Supermassive Games is a game studio run on agile lines. They do all their planning on walls that remain for the duration of the project. They find that the teams self-organise very well. There were interesting questions on how to interface an agile organisation with the game publishers who don’t work like that, which he admitted is a challenge, but he says that once they see that you deliver, you quickly build up trust.
What makes a good domain specific language?
This session was mainly an exercise in creating domain specific languages. It emphasised the importance of starting with the domain and problem description rather than starting with some code you want to make more DSLy.
Paradigms of Programming: Hands On
We coded a simple problem and modified it, using four different programming styles: Procedural, Object Oriented, Functional and Rules Based. Since lots of OO code is more procedural than OO, we were encouraged to adopt a hardcore OO approach for the OO section to distinguish the two more – using an agent style, and not allowing return values. This in itself was an interesting exercise. They also made the point that it is possible to use the different paradigms in languages that aren’t specifically designed to support them, with varying degrees of fit. This means that even if you know you are using Java or Javascript, it’s worth considering what paradigm a particular problem might best be approached with.
Summary
I also heard lots of good things said about the Persona Driven development workshop that Sarah and Duncan ran.
For me the central theme of the whole conference was that too often we jump to solutions before properly understanding the problem. These solutions are often correct but may not be the best solutions and if you’ve jumped to the wrong approach you end up stuck in spiralling complexity and a greater cost in time and effort. It’s worth taking time at the beginning of each problem to consciously leave your prejudices aside as much as possible and spend some time trying to understand the problem in detail before jumping to any sort of solution, no matter how obvious.