Today's keynote was given by Phil Nash, and was entitled "The Congreuent Programmer". The message seemed to be that we live our lives according to a set of beliefs, values and principles. If these are aligned then we are fine, otherwise we find ourselves in a state of cognitive dissonance. One example I have for this is that I believe in TDD (at least to some degree!), but I very rarely find myself practicing it!
Next I went to a talk on "Go, D, C++ and the multicore revolution" by Russel Winder. The aims of this talk were to convince me that shared memory multi-theading is not appropriate for application development (I don't need much convincing on this point!) and also that the new threading related features of C++ 11 may have saved it from the dustbin.
The multicore revolution is already here. I'm writing this on my dual core iPad and chances are you (hi mum!) are reading it on a multicore machine of some description. Since the multicore revolution, software has started to lag behind hardware. As software engineers, we're the people holding things up!
The distinction was made between concurrency (a design tool) and parallelism (a tool for improving performance). Three models of controlling concurrency were then presented. None of the are new ideas, but they are well understood tools that are only now beginning to be recognised as important.
The actor model controls concurrency by having multiple independent processes (important to note that this process need not be a separate OS process, it's just a lump of code with an independent address space) communicating via asynchronous messages. Erlang is an example of a language that has direct support for the actor model.
The data flow model is a spreadsheet model where the computation reacts to changes in inputs. this has a role in big data as a counterpart to the map/reduce app. By running a data flow net as a continuous query that updates based only on the diff, it's possible to get more immediate results. Lucid is an old, but interesting, example of a data flow language.
Finally, Communicating Sequential Processes (CSP) was presented. This is a formal model of concurrency where processes communicate via synchronous messages. Go reinvented CSP and called it go-routines.
Next Russel presented a simple example that calculated Pi. The example was kept consistent as the languages moved to higher level abstractions, from C and pthreads to Go and D with C++ and MPI in between. The obvious point was higher level abstractions make things easier to understand. All in all, I enjoyed this talk!
Henrik Berglund ran a quick 45 minute session on "Real Teams". I have to admit I initially chose this one purely because the door was open so it was a break from the unbelievably hot rooms! Luckily for me this turned out to be an excellent choice. The introduction talked about the curious case of the astronauts that went on strike. Despite being highly trained, military disciplined and very intelligent a bunch of astronauts went on strike in space simply because the working conditions were so hard. Building great teams is hard!
Getting the conditions right for a team is very important and Henrik outlined some of the things that he had seen with successful teams.
- People need influence over their working conditions. This can be achieved by using self managing teams that have clear authority. Delegation poker might be one tool to try out for this.
- Compelling direction. A vision, a product, a sprint goal. One of the more interesting points was that goals should be challenging and it was suggested that a 50% failure rate was optimum. I definitely want to try this when I get back to work!
- Clear boundaries. Understand who is on the team.
- Nobody succeeds unless everyone succeeds. This avoids the done vs done done dilemma. Problems should be given to teams not people.
- Trustworthy feedback based on results. No proxies between users and the teams. The role of the product manager is to be the vision guy, not to shield customers from engineers.
- Need to depend on each others skills. It's OK to specialize and build up independent skills (got to be careful of the bus number!)
- Be able to give negative feedback if needed. This needs trust on the team and this takes time to build up.
Team building requires effort. Undertsanding the needs and motivations of your colleagues is an important part of working together
After this talk I caught the tail-end of "When only C will do". C is supported everywhere and has a standard application binary interface (ABI). This ubiquity makes it an easy choice. C++ doesn't have a standard API and embedded devices may choose to drop some features (e.g. runtime type information or exceptions) which makes life harder. The conclusion seemed to be that most of the time you can use C++, but you may need to expose a C interface to be compatible with the rest of the world.
The afternoon finished with a talk on "Refactoring to Functional". I don't think I was the target audience for this presentation. The talk introduced some foundational functional concepts but through the medium of Google's Java's Guava library (curiously its missing a fold/reduce operator). This has some of the worst syntax I have ever seen. The noise to useful ratio is stupidly high and it just made me so grateful for C#. Yuck!
They chose this style because it made the core logic simpler (and presumably eventually their brains learned to unsee the syntactic abominations). They did try Scala, but found that you had to think at both the Scala and Java layers. I think using the functional style in a language without first class functions is a mistake. It's like trying to write C in an object-oriented style. You can do it, but you can constantly fighting it and that's not good. Maybe Java 8 will resolve these problems in a few decades.