Conference Call

Conferences never fail to leave me somewhat humbled. Normally I suppress the fact that I don’t know enough (because its depressing to acknowledge that all the time), but listening to people much smarter and more successful than me speak at conferences really does hammer the point home. I wouldn’t necessarily consider this a bad thing though, as aware of the limitations of your knowledge is almost always better than believing you are amazing and know all the things.

If you caught my blog post last week, you’ll know that I was planning on heading to DDD Brisbane and Yow! over the last couple of days. Well, I went and did that, and now I’m tired. Richer in knowledge yes, but also tired.

I’m going to use this blog post to give a quick summary of the sessions across both of those events that I thought were the most interesting, both in order to summarise and solidify my own thoughts on the subject and to share my experiences with others.

DDD Brisbane

Panel: What is Quality Code (Various)

Its interesting to see what a small group of people consider to be quality code. Its one of those really common questions that is hard to answer by virtue of the fact that everyone really does think about quality in a different way. The panel here was no exception, but there was a common thread of mutability being one of the major measures of quality. Code that is changeable and can adapt in the face of the changing world is of a much higher quality than code that can’t change. A lot goes into making code changeable (like making it understandable first), but in my opinion that’s what it comes down to. This of course means that you should be rightly wary of decisions that make future change difficult (architecture is definitely one of those things).

Parsing Text: The Programming Superpower You Need at Your Fingertips (Nicholas Blumhardt)

Nick gave an interesting talk on parsing data structures from text representations. To be honest, text parsing is one of those things that I tend to shy away from unless absolutely necessary, because it can be very difficult to get right. The actual parsing itself (assuming you have a well defined grammar of some sort) isn’t necessarily the hard part, but the functionality around it (error detection and notification mostly) can be exceedingly difficult. Nick demonstrated solving the problem from two different directions, the first using a composable object-oriented approach (an Integer class, a character class, a Double class build from 2 Integers and a Period) and then improved on that design by using a more fluent syntax (using his Sprache library).

Back to Basics: Simple, Elegant and Beautiful Code (Andrew Harcourt)

Andrew was as entertaining as always. One of the most important things he mentioned was make sure you include personal and team happiness in the mix when you’re optimising your outcomes. Its often left behind in the rush to deliver features or to do things perfectly, but it can definitely have one of the biggest impacts when it comes to your own (and your teams) ability to deliver anything of import. He said a bunch of other stuff as well, but the happiness point really resonated with me.

Sweet You’re Agile! Now What? (Chris Gilbert)

Chris talked about Agile. Other than the normal agile themes, processes and practices he mentioned one particular approach for standups that I thought was interesting (and that I will be trying out in the next couple of days). Instead of going around the group getting everyone to talk about what they did/are doing/are blocked on, he suggested going through the board and asking what the team can do to deliver each the stories/tickets that are in process. He called this process “walking the board” and I think it would definitely be more useful than the standard standup (which can very easily become a progress report). The focus is shifted to actually delivering (or asking the questions that lead to delivery) instead of just activity.

What is a Compiler: We Thought We Knew… (Mads Torgersen)

This talk was amazing. Mads exudes a real enthusiasm for the subject (the new C# compiler and its domain model) and its hard not to get excited when he does. He went through the challenges in merging the two codebases that understand C# (the compiler and the IDE) and the structure that now lives underneath the hood (immutable but shared syntax and parser trees). He also demonstrated some particularly cool things like being able to write customer analysers (so you can highlight when someone is doing something that you discourage, like creating public static methods) and fixers (that allow you to regenerate the code such that it no longer has the problem) and the ability to run C# code from a command line in a REPL.

Yow!

Delivery Mapping: Turning the Lights On (Dan North)

Dan is another one of those people that I’ve heard of, but never heard speak before. He’s a really good speaker, and he was presenting some very interesting things so this session stuck in my mind quite persistently (unlike some of the other talks that are already getting a bit fuzzy). Dan spoke about a different method of organising agile software development at scale. His idea was to facilitate your people organising themselves into short lived teams (opposing accepted practices) so that they rally around problems rather than around the team itself. He then talked at length about helping to identify those teams by determining what skills you have available (and what skills you lack) and then cross referencing that with the skills that you need to solve a particular problem.

The Future of Software Engineering (Glenn Vanderburg)

Glenn talked (almost lectured really) about the history of software engineering (as compared to other, more mature forms of engineering) and how relatively recently there has been a lot of sentiment that software engineering is not really engineering because its different at some fundamental level that makes it incompatible. Glenn disagrees, saying that its more likely we really only tried a set of processes very closely modelled on another engineering discipline, and when it didn't work for us we tried to throw out the entire concept rather than trying something different. Glenn reiterated a sentiment that I’ve heard before (but can’t really remember from where) about the profession misunderstanding exactly what constitutes design when it comes to software development. The code (and everything leading up to it) is the design, rather than the code being the artefact. This means of course that an architectural blueprint in other engineering disciplines (being a set of instructions to follow for construct something) is equivalent to the source code in software development (being a set of instructions to accomplish something). This flips the typical cost model, because materials are usually the most expensive part of building something, but for software, building the thing using the blueprint is essentially free. A concept I agree with.

Engineering and Exploring the Red Planet (Anita Sengupta & Kamal Oudrhiri)

I mention this session (which was one of the day 2 keynotes) mostly because it was incredibly interesting to see the engineering challenges that went into landing the most recent Rover on Mars. Specifically it was pretty hilarious that at day 200 into the expedition, some sort of bug prevented the primary computer on the Rover (there are two) from receiving commands, so they had to force it to shut down and hope the backup computer turned itself on. They expected the backup to be available within 60 seconds, but it didn’t come back for 3+ minutes. The hilarious part, the delay between primary down –> backup available was actually feature that was added late in the development that not everyone was aware of, so they were panicking for every second in that 3 minute delay.

Agile is Dead – Long Live Agility (Dave Thomas)

While I’ve heard of Dave Thomas (one of the original writers of The Manifesto for Agile Software Development), I’ve never actually heard him speak. He espoused a lot of things that I’ve been struggling with regarding agile for a while now, including its commercialisation, the fact that one does not do Agile and that most people seem to have lost sight of what it was originally meant to accomplish. Its really about solving problems incrementally, which for software usually means delivering small amounts of functionality on a regular basis and adapting to the feedback loop that allows. Dave gave his incredibly polished and detailed plan for increasing agility, which I will paraphrase here because really everyone should see it:

1. Make a small step forward.
2. Get feedback.
3. Adjust

As you can see, and incredibly complex and fully realised process model. He should sell it through a consultancy.

Designing for Failure: Scaling Uber’s Backend by Breaking Everything (Matt Ranney)

It was refreshing to hear Matt talk about how successful organisations make mistakes just as much as everyone else. He spoke at length about the various failures that had occurred in Uber’s software systems over the last year or so and how they were eventually dealt with. Usually speakers talk at conferences about how their organisation does X and Y amazingly and so should you, so it was great to hear about how Uber has made a bunch of mistakes during their incredible growth. As a bonus the background images for some of his slides showed a visualisation of the Uber traffic through various major US cities over a 24 hour period, which it itself was incredibly interesting.

Making Hacking Childs Play (Troy Hunt)

Last year at DDD I had the pleasure of watching OJ Reeves do some hacking. Troy’s talk this year was in a similar vein, but more presentational rather than demonstrative (although there were definitely demonstrations, like making any old website do the Harlem Shake. Well, almost any, except Troys personal project Have I Been Pwned that is. Troy went through a lot of different security stuff, mostly themed around how hacking can be easy enough for even children to do (and bored kids do a lot of things). The best part of the session? Troy had set up a WIFI Pineapple as a public WiFi in the room. Not super interesting by itself, but he also set it up so that it looked like any unsecured public WiFi that a device had previously connected to. This meant that any mobile device in the room that had previously connected to an unsecured public WiFi at any point in the past was quite happy to connect to this one and just jam all its normal traffic through. Result: Troy could see and record and HTTP traffic from a number of different phones in the room. Hilarious.

DevOps @ Wotif – Making Easy = Right (Alexandra Spillane and Matt Callanan)

Nothing revolutionary here, but a very solid talk about the process that WotIf went through in order to solve the problems they were having with an incredibly over-constrained operations team and generally low morale (because no-one was delivering). It was enlightening to hear someone talk about the application of those DevOps principles within an organisation that still needed to have a fair amount of control. They did it involving standards and checkpoints, which honestly is probably the only way you can migrate an organisation from the old school way of thinking to the newer. I imagine that eventually, with mature enough teams and ingrained practices they will probably start to drop some of the formality, but during the transformative early stages, that sort of thing is critical.

The Mother of all Programming Languages Demos (Sean McDirmid)

Sean’s talk was interesting, if not immediately applicable to my day to day problems. He spoke of different/new ways of programming involving letting the computer help you find a solution, rather than you just writing one. I think it was mostly about decreasing the time in feedback loops, because he demoed a pseudo programming language (it was Python-esque), that allowed you to run and change code in real-time. It could do things like go backwards and forwards in time for animations (including visualising the next 200 positions of your object) and scrubbing through possible values for your variables and functions. Like I said, interesting, but probably not useful for another few years at least (which is what I would expect our of a talk from a member of the Microsoft research department).

Conclusion

For me and for the cost involved (a paltry $30), DDD is a no brainer. There is really no reason to not go to that beautiful little conference and listen to your peers (and betters) talk about interesting things.

Yow on the other hand…

I’m not 100% convinced of the value for money that actually attending the Yow conference provides. Don’t get me wrong, it was certainly interesting, and going to these sorts of things is more about promoting a culture of learning and improvement, rather than extracting physical value from the conference itself. Its just that if you wait a little bit you can see absolutely everything that was presented, in the comfort of your office or home, for nothing at all.

I suppose for a more outgoing person the main benefit is in being in the same place as so many smart people, so you can pick their brains and have interesting discussions about all sorts of things. What I mostly see though is people sticking together in the groups defined by the organisations that they came from (myself included) because its just easier that way. Granted, not everyone does this, but it definitely seemed to be more common than not.

If promoting discussions between smart people was really was the case though, there would be more dedicated time for sitting down in smaller groups and discussing things. Maybe instead of focusing the conference around speakers and sessions, you could organise to have lots of small rooms with whiteboards and materials available. Give each room a topic of some sort (where you still have one or two people facilitating) and then let it all sort itself out.

Much much harder to organise and sell I imagine, but I’d be more comfortable paying for that sort of thing.

That sounds like real value.