With no need for additional fanfare, I now present to you the continuation of last weeks post about DDD 2018.

Break It Down

My fourth session for the day was presented by the wonderful Larene Le Gassick.

As a woman in tech, Larene was curious about the breakdown of gender for the speakers participating in the various Brisbane based Meetups, so she built a bot that would aggregate all of that information together and post it into Slack, thus bringing the data out into the open.

Well, the word “bot” might be overselling it.

It was Larene. Larene was the bot.

Regardless of the mechanism, there was some good tech stuff in there (including a neat website using a NES css style), but the real value from the process was in the data itself, and the conversation that it started when presented in a relatively public place on a regular basis.

From my own experience, the technology industry and software development in particular, does seem to be male dominated. I’m honestly unsure whether that’s a good or bad thing, but I am fully in favour of encouraging more participation from anyone who wants to get involved, regardless of sex, race or any other discriminating factor you can think of.

DDD in particular is pretty great for this sort of inclusiveness actually, sometimes resulting in surprising feedback.

Actually, This Time It Does Mean What You Think It Means

The fifth session that I attended was delivered by Steve Morris in his usual style. Which is to say, awesomely.

To be honest, I probably could have skipped this session as it was basically Domain Driven Design 101, but it was still pretty useful as a refresher all the same.

Domain driven design is in a weird place in my head. The blue book is legendary for how dry and difficult to read it is, but there is some really great stuff in there. Actually trying to understand and then model the domain that your software is operating in seems like an extremely good idea, but its one of those things that’s really hard to do properly.

I’ve inherited at least one system built by people who had clearly read some of the book, but what I ended up with was a hard to maintain and understand system, so I’m going to assume that they did it wrong. I don’t know how to do it right though.

Regardless, I’ll keep trying to head in that direction as best I can.

Intelligent Design

The sixth session of the day was a presentation on UX and Design by Jamie Larkin. Her first such presentation in fact, which was actually really hard to tell, because she did extremely well.

The session itself was fantastic.

I’ve always questioned why developers seem to shy away from design (or why designers shy away from development), and I like to think that I’ve tried to keep UX high in my priority list when implementing things in the past. Having said that, I’m definitely not cognizant of many design patterns and principles, so it was really nice to see something with experience in both design and development talk about the topic.

The main body of the talk was focused on UX design patterns presented in such a way that they would be relevant to developers. Even better, the presentation used real websites (MailChimp and Air B&B) as examples. This was pretty great, because it paired the generic design principles with concrete examples of how they had been applied, or in some cases, how the design principles had been broken and how it was negatively affecting the resulting user experience.

Some specific takeaways:

• Consistency is key. If you’re building something inside a system, its probably a good idea to match the style that is already present, even if it results in a sub-optimal experience. Disjointed design can be extremely damaging to the user experience.
• Put things where users will expect to find them. This might mean bending towards common interaction paradigms (i.e. it looks like Word), or even just spending the time to understand your users so that interaction elements appear in places that make sense to them.
• Understand what the user wants to accomplish and focus the experience around that. That is, don’t just present information or actions for no reason, focus them around goals and intent.
• Consider the context in which the user wants to use the software. Are they on a train? In a car? At home in bed? Smart answers to these questions can make a huge difference to the usability of your service.
• Feedback to the user while operating your system is essential. Things like hover highlights, immediate feedback when validating user input and loading or processing indicators can really reinforce in the users mind that they are doing something meaningful and that the system recognizes that

At the end of the session I left richer in knowledge than when I arrived, so I consider that a victory.

Don’t Trust Your Brain

The last session I attended was a presentation on cognitive bias by Joseph Cooney.

For me, this was the most interesting session of the day, as it really reinforced that I should never trust the first thing that comes into my brain, because it was probably created as a result of a lazy thought process that took as many shortcuts as it could.

I’ve been aware of the concept of cognitive bias for a while now, but I didn’t really understand it all that well. To be honest, I still don’t really understand it all that well, but I think I know more about it than I did before the session, so that’s probably a good outcome.

To quote my notes from the session verbatim:

Cognitive bias is the situations where people don't make rational decisions for a number of reasons (which may not be conscious). Kind of like an optical illusion, but harder to dispel.

Not the greatest definition in the world, but good enough to be illustrative I think.

What it comes down to is that the human brain appears to operate via a combination of two systems:

• The first system is automatic, effortless, fast and specialized. Its always running in the background and offers up images and feelings as opposed to raw data. It thinks in stories and deals with ambiguity well, even retconning past events to fit into a new model as necessary.
• The second system is deliberate, effortful, slow, general purpose and incredibly lazy. That is, you have to actually try to engage it, as its expensive to run.

The first system does a lot of work, and helps you to make decisions quickly and without fuss. Unfortunately, sometimes it takes a shortcut that is less appropriate than it could be and makes a non-ideal decision, thus cognitive bias.

As conscious beings though, we can choose to be aware of the decisions being made by the first system, question them and kick the second system into gear if we need to (performing the rational and data based analysis that we thought we were probably doing in the first place).

I’m sure I haven’t done the topic justice here though, so if you’re interested, I recommended starting at the article in Wikipedia and discovering all the ways in which I have misinterpreted and otherwise misrepresented such an interesting facet of the human psyche.

In summary, 10/10, would listen to talk again.

Conclusion

Unfortunately, I had to bug out before the locknote (a session on how to support constant change), but all in all the day was well worth it.

Its always nice to see a decent chunk of the Brisbane Developer Community get together and share the knowledge they’ve gained and the lessons they’ve learned over the last year. DDD is one of those low-key conferences that just kind of happens (thanks to the excellent efforts of everyone involved obviously), but doesn’t seem to have the underlying agenda that others do. It really does feel like a bunch of friends getting together to just chat about software development stuff, and I appreciate that.

If you get a chance, I highly recommend attending.

This post is a week later than I originally intended it to be, but I think we can all agree that terrifying and unforeseen technical problems are much more interesting than conference summaries.

Speaking of conference summaries!

DDD Brisbane 2018 was on Saturday December 1, and, as always, it was a solid event for a ridiculously cheap price. I continue to heartily recommend it to any developer in Brisbane.

In an interesting twist of fate I actually made notes this time, so I’m slightly better prepared to author this summarization.

Lets see if it makes a difference.

I Don’t Think That Word Means What You Think It Means

The first session of the day, and thus the keynote, was a talk on Domain Driven Design by Jessica Kerr.

Some pretty good points here about feedback/growth loops, and ensuring that when you establish a loop that you understand what indirect goal that you are actually moving towards. One of the things that resonated the most with me here was how most long term destinations are actually the acquisition of domain knowledge in the brains of your people. This sort of knowledge acquisition allows for a self-perpetuating success cycle, as the people building and improving the software actually understand the problems faced by the people who use it and can thus make better decisions on a day to day basis.

As a lot of that knowledge is often sequestered inside specific peoples heads, it reinforced to me that while the software itself probably makes the money in an organization, its the people who put it together that allow you to move forward. Thus retaining your people is critically important, and the cost of replacing a person who is skilled at the domain is probably much higher than you think it is.

A softer, less technical session, but solid all round.

Scale Mail

The next session that I attended was about engineering for scale from a DDD staple, Andrew Harcourt.

Presented in his usual humorous fashion, it featured a purely hypothetical situation around a census website and the requirement that it be highly available. Something that would never happen in reality I’m sure.

Interestingly enough, it was a live demonstration as well, as he invited people to “attack” the website during the talk, to see if anyone could flood it with enough requests to bring it down. Unfortunately (fortunately?) no-one managed to do any damage to the website itself, but someone did managed to take out his Seq instance, which was pretty great.

Andrew went through a wealth of technical detail about how the website and underlying service was constructed (Docker, Kubernetes, Helm, React, .NET Core, Cloudflare) illustrating the breadth of technologies involved. He even did a live, zero-downtime deployment while the audience watched, which was impressive.

For me though, the best parts of the session were the items to consider when designing for scale, like:

• Actually understand your expected load profile. Taking the Australian Census as an example, it needed to be designed for 25 million requests over an hour (i.e. after dinner as everyone logged on to do the thing), instead of that load spread evenly across a 24 hour period. In my opinion, understanding your load profile is one of the more challenging aspects of designing for scale, as it is very easy to make a small mistake or misunderstanding that snowballs from that point forward.
• Make the system as simple as possible. A simpler system will have less overhead and generally be able to scale better than a complex one. The example he gave (his Hipster Census), contained a lot of technologies, but was conceptually pretty straight forward.
• Provide developers with a curated path to access the system. This was a really interesting one, as when he invited people to try and take down the website, he supplied a client library for connecting to the underlying API. What he didn’t make obvious though, was that the supplied client library had rate limiting built in, which meant that anyone who used it to try and flood the service was kind of doomed from that start. A sneaky move indeed. I think this sort of thing would be surprisingly effective even against actual attackers, as it would catch out at least a few of them.
• Do as little as possible up front, and as much as possible later on. For the census example specifically, Andrew made a good point that its more important to simply accept and store the data, regardless of its validity, because no-one really cares if it takes a few months to sort through it later.
• Generate access tokens and credentials through math, so that its much easier to filter out bad credentials later. I didn’t quite grok this one entirely, because there was still a whitelist of valid credentials involved, but I think that might have just been for demonstration purposes. The intent here is to make it easier to sift through the data later on for valid traffic.

As is to be expected from Andrew, it was a great talk with a fantastic mix of both new and shiny technology and real-world pragmatism.

Core Competencies

The third session was from another DDD staple, Damien McLennan.

It was a harrowing tale of one mans descent into madness.

But seriously, it was a great talk about some real-world experiences using .NET Core and Docker to build out an improved web presence for Work180. Damien comes from a long history of building enterprisey systems (his words, not mine) followed by a chunk of time being entirely off the tools altogether and the completely different nature of the work he had to do in his new position (CTO at Work180) threw him for a loop initially.

The goal was fairly straightforward; replace an existing hosted solution that was not scaling well with something that would.

The first issue he faced was selecting a technology stack from the multitude that were available; Node, Python, Kotlin, .NET Core and so on.

The second issue he faced, once he had made the technology decision, was feeling like a beginner again as he learned the ins and outs of an entirely new thing.

To be honest, the best part of the session was watching a consummate industry professional share his experiences struggling through the whole process of trying a completely different thing. Not from a “ooooo, a train wreck” point of view though, because it wasn’t that at all. It was more about knowing that this is something that other people have gone through successfully, which can be really helpful when its something that you’re thinking about doing yourself.

Also, there was some cool tech stuff too.

To Be Continued

With three session summaries out of the way, I think this blog post is probably long enough.

Tune in next week for the thrilling conclusion!

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.

Well, for me anyway, because the conferences I tend to go to happen around this time of year.

I’m off to two opportunities for self-improvement this year, DDD Brisbane and Yow!. Unfortunately (fortunately?) they are scheduled extremely close together (Saturday, Monday, Tuesday), so I’ve got a busy few days full of learning coming up. Still, a little busyness is a small price to pay for knowledge. “Scientia potentia est” after all.

I don’t know any Latin beyond what the internet tells me.

DDD Brisbane I had to pay for out of my own pocket (a mere AUD $30, incredibly affordable for anyone looking to take advantage of the experience of others), but my employer (Onthehouse Group) was nice enough to cover the costs of Yow!, so I didn’t have to take that one on the chin.

Last year I only managed to attend DDD, so it will be nice to head off to Yow! this year to absorb all that delicious knowledge. I’ll probably do a follow up post after the conferences are over (assuming I yet live),  but for now this post will be a quick one highlighting some of the things that I’m looking forward to.

Developers, Developers, Developers

There is some good stuff happening at DDD this year. Personally, I’m looking forward to the following sessions.

Panel: What is Quality Code

This is one of those all-star panels that will probably dump massive amounts of experience in a very short amount of time. Featuring some of the more well known players in the Software Development space (in Brisbane at least), I’m sure it will be both engaging and educational.

Designing an API

Indu Alagarsamy & John Simons talk is topical for me, because we are currently investing in the design and implementation of an API that will expose parts of our flagship software that were previously unavailable to external consumers. I’m interested to see what these two speakers will offer in terms of new information, or lessons learnt.

Back to Basics: Simple, Elegant, Beautiful Code

Listening to Andrew Harcourt give a talk is always both entertaining and enlightening, and I’m sure this talk will be no different. Its always a goal of mine to write simple code, and I considering myself a craftsman when it comes to developing software, so I’m interested in what sort of things Andrew has to say on the matter.

Sweet You’re Agile! No What?

Its always interesting to see what people have to say about Agile, and I wonder what Chris has to add to all the other stuff floating about out there.

Yow

I’ve never actually been to a Yow! conference before, though I have watched quite a lot of the videos that they put up after the fact (you can view all of the previous Yow! videos for free at the Eventer website). It should be a good opportunity for me, even though its a much larger, less personal conference. This year I’m looking forward to the following sessions.

Delivery Mapping: Turning the Lights On

Writing software is all well and good, but if you can’t deliver it in a timely, reliably fashion, what does it really matter? I’m hoping this session will provide some new information on that front.

Pragmatic Microservices: Whether, When and How to Migrate

Whether or not the use a microservice based architecture is something we’re currently struggling with right now, so I’m very interested in seeing real examples from big companies (on both sides of the argument) accompanied by some sort of analysis into the desirability of the approach.

Property Based Testing: Shrinking Risk in Your Code

I’m a big proponent of testing, and while I have heard some things about property based testing, my level of knowledge about it would barely fill a thimble. I’m hoping the the content of this session will enlighten me somewhat.

Agile is Dead (Long Live Agility)

In the same sort of vein as the Agile talk Chris is giving at DDD, I’m curious to hear what one of the original founders of the Agile Manifesto has to say on the subject. Personally, I think not enough people pay attention to Agile values and instead focus on the process, thinking that makes them “agile”.

Designing for Failure: Scaling Uber’s Backend By Breaking Everything

Now this is the kind of talk I can get behind. Using AWS as our primary hosting mechanism has only solidified in my mind the fact that anything can break at any moment, so you might as well be prepared for it. I wonder if this session will feature similar concepts to Netflix and their legendary Chaos Monkey, Gorilla and Kong.

Making Hacking Childs Play

Troy Hunt is pretty legendary in the security field, so I’m sure he has to say will have excellent ramifications for the way I think about security.

DevOps @ Wotif: Making Easy = Right

Looking back I’ve always been interested in making sure that software developers are involved at every step of the software pipeline, and deployment/support is no exception. The relatively new culture around DevOps only reaffirms that sort of attitude, taking operational concerns into the programming space. Hopefully this talk will add more fuel to the fire.

Conclusion

The downside of these sorts of conferences is that you simply can’t see everything. At least with Yow! I will be able to watch the videos later, which I certainly will be doing. There were some particular hard decisions made in my list above, and I don’t want to miss out on anything amazing.

As an aside, it really does feel like there is never an end to learning new things in this field and that can be a combination of exhilarating and exhausting. The problem is, if you stop to take a breather, everything moves so fast that you’re already behind the curve. One day it might settle down, but I can’t imagine that’s going to happen in my lifetime.

I’m still not entirely sure if anyone actually reads this blog, but if you do, and you somehow recognise me at either of the conferences above, come and say hi.

I should have posted about this last week, but I got so involved in talking about automating my functional tests that I forgot all about it, so my apologies, but this post is a little stale. I hope that someone still finds it useful though, even as an opinion piece.

Automating the functional tests isn’t going so well actually, as I’m stuck on actually executing TestExecute in the virtual environment. Its dependent on there being a desktop for it to interact with (no doubt for the purposes of automation, like mouse clicks and send keys and stuff) and I’m executing it remotely from a different machine on a machine that is not guaranteed to have any available interactive user sessions. Its very frustrating.

Developer, Developer, Developer was hosted at QUT on Saturday 6 December, and it was great. This post is primarily to give a shoutout to everyone that I saw speak on the day, as well as some of my thoughts about the content. Its not a detailed breakdown of everything that I learned, just some quick notes.

First up, the conference would not have been possible without the sponsors, which I will mention here because they are awesome. Octopus Deploy, DevExpress and CampaignMonitor were the main sponsors, with additional sponsorship from Readify, SSW, Telerik + more. The whole day only cost attendees $30 each, and considering we had 2 massive lecture theatres and 1 smaller room at QUT for the entire day, food and drinks and then prizes at the end, the sponsors cannot be thanked enough.

Octopussy

The first talk of the day (the keynote) was from Paul Stovell, the Founder of Octopus Deploy.

Paul talked a bit about the origins of Octopus Deploy through to where the company (and its flagship product) are now, and then a little bit about where they are heading.

I found it really interesting listening to Paul speak about his journey evolving Octopus Deploy into something people actually wanted to pay money for. Paul described how Octopus was developed, how the company grew from just him to 5+ people, their first office (where they are now) and a number of difficulties he had along the way as he himself evolved from a developer to a managing director. I’ve been reading Paul’s blog for a while now, so there wasn’t a huge amount of new information, but it was still useful to see how everything fit together and to hear Paul himself talk about it.

I don’t think I will ever develop something that I could turn into a business like that, but its nice to know that it is actually possible.

A big thank you to Paul for his presentation, and to Octopus Deploy for their sponsorship of the event.

Microservices

Mehdi Khalili presented the second talk that I attended, and it was about microservices. Everyone seems to be talking about microservices now (well maybe just the people I talk to), and to be honest, I’d almost certainly fail to describe them within the confines of this blurb, so I’ll just leave a link here to Martin Fowlers great article on them. Its a good read, if a little heavy.

Long story short, its a great idea but its super hard to do it right. Like everything.

Mehdi had some really good lessons to share from implementing the pattern in reality, including things like making sure your services are robust in the face of failure (using patterns like Circuit Breaker) and ensuring that you have a realistic means of tracking requests as they pass through multiple services.

Mehdi is pretty awesome and well prepared, so his slides are available here.

I really should have written this blog post sooner, because I can’t remember a lot of concrete points from Mehdi’s talk, apart from the fact that it was informative while not being ridiculously eye-opening (I had run across the concepts and lessons before either through other talks or blog posts). Still, well worth attending and a big thank you to Mehdi for taking the time to put something together and present it to the community.

Microservices 2, Electric Boogaloo

I like Damian Maclennan, he seems like the kind of guy who isn’t afraid to tell you when you’re shit, but also never hesitates to help out if you need it. I respect that attitude.

Damian followed Mehdi’s talk on microservices, with another talk on microservices. I’ve actually seen Damian (and Andrew Harcourt) talk about microservices before, at the Brisbane Azure User Group in October, so I contemplated not going to this talk (and instead going to see William Tulloch tell me why I shouldn’t say fuck in front of the client). In the end I decided to attend this one, and I was glad that I did.

Damian’s talk provided a good contrast to Mehdi’s, with a greater focus on a personal experience that he had implementing microservices. He talked about a fictional project that he had been a part of for a company called “Pizza Brothers” and did a great walkthrough of the state of the system at the point where he came onto the project to rescue it, and how it changed. He talked and how he (and the rest of the team) slowly migrated everything into a Service Bus/Event based microservice architecture, and how that dealt with the problems of the existing system and why.

He was clear to emphasise that the whole microservices pattern isn’t something that you implement in a weekend, and that if you have a monolithic system, its going to take a long time to change it for the better. Its not an easy knot to unpick and it takes a lot of effort and discipline to do right.

I think I appreciate these sorts of talks (almost like case studies) more than any other sort, as they give the context behind the guidelines and tips. I find that helps me to apply the lessons in the real world.

Another big thank you to Damian for taking the time to do this.

Eventing, Not Just for Services

Daniel Little was the first presentation after lunch. He spoke about decoupling your domain model from the underlying persistence, which is typically a database.

The concepts that Daniel presented were very interesting. He took the event based design sometimes used in microservices, and used that to disconnect the domain model from the underlying database. The usage of events allowed the domain to focus on actual domain logic, and let something else worry about the persistence, without having to deal with duplicate classes or dumbing everything down so that database could understand it.

I think this sort of pattern has a lot of value, as I often struggle with persistence concerns leaking into an implementation and muddying the waters of the domain. I hadn’t actually considered approaching the decoupling problem with this sort of solution, so the talk was very valuable to me.

Kudos to Daniel for his talk.

Cmon Guys, UX Is A Thing You Can Do

This one was a pair presentation from Juan Ojeda and Jim Pelletier from Kiandra IT. Juan is a typical user experience (UX) guy, but Jim is a developer who started doing more UX after working with Juan. Jim’s point of view was a bit different than the normal UX stuff you see, which was nice.

I think developers tend to gloss over the user experience in favour of interesting technical problems, and the attendance at this talk only reinforced that opinion. There weren’t many people present, which was a shame because I think the guys gave some interesting information about making sure that you always keep the end-user in mind whenever you develop software, and presented some great tools for accomplishing that.

User experience seems to be one of those things that developers are happy to relegate to a “UI guy”, which I find to be very un-agile, because it reduces the share responsibility of the team. Sure, there’s going to be people with expertise in the area, but we shouldn’t shy away from problems in that space, as they are just as interesting to solve as the technical ones. Even if they do involve people instead of bits and bytes.

Juan and Jim talked about some approaches to UX, including using actual users in your design (kind of like personas) and measuring the impact and usage of your applications. They briefly touched on some ways to include UX into Agile methodologies and basically just reinforced how I felt about user experience and where it fits in into the software development process.

Thanks to Juan and Jim for presenting.

Security is Terrifying

The second last talk was by far the most eye-opening. OJ Reeves did a great presentation on how we are all doomed because none of our computers are secure.

It made me never want to connect my computer to a network ever again. I might not even turn it on. Its just not safe.

Seriously, this was probably the most entertaining and generally awesome talk of the day. It helps that OJ himself exudes an excitement for this sort of stuff, and his glee at compromising a test laptop (and then the things accessible from that laptop) was a joy to behold.

OJ did a fantastic demo where he used an (at the time unpatched) exploit in Internet Explorer (I can’t remember the version sorry) and Cross Site Scripting (XSS) to gain administrative access over the computer. He hid his intrusion by attaching the code he was executing to the memory and execution space of explorer! I didn’t even know that was possible. He then used his access to do all sorts of things, like take photos with the webcam, copy the clipboard, keylog and more dangerously, pivot his access to other machines on the network of the compromised machine that were not originally accessible from outside of the network (no external surface).

I didn’t take anything away from the talk other than terror and that there exists a tool called Metasploit and Meterpreter which I should probably investigate one day. Security is one of those areas that I don’t most developers spend enough time thinking about, and yet its one with some fairly brutal downsides if you mess it up.

You’re awesome OJ. Please keep terrifying muppets.

So You Want to be a Consultant

Damien McLennan’s second talk for the day was about things that he has learnt while working at Readify as a consultant (of various levels of seniority), before he moved to Octopus Deploy to be the CTO there.

I had actually recently applied and was rejected for a position at Readify *shakes fist*, so it was interesting hearing about the kinds of gigs that he had dealt with, and the lessons he learnt.

To go into a little more detail about my Readify application, I made it to the last step in their interview process (which consists of Coding Test, Technical Interview, Culture Interview and then Interview with the Regional Manager) but they decided not to offer me the position. In the end I think they made the right decision, because I’m not sure if I’m cut out for the world of consulting at this point in my career, but I would have appreciated more feedback on the why, so that I could use it to improve further.

Damian had a number of lessons that he took away from his time consulting, which he presented in his typical humorous fashion. Similar to his talk on microservices earlier in the day, I found that the context around Damian’s lessons learnt was the most valuable part of the talk, although don’t get me wrong, the lessons themselves were great. It turns out that most of the problems you have to deal with as a consultant are not really technical problems (although there are plenty of those) and are instead people issues. An organisation might think they have a technical problem, but its more likely that they have something wrong with their people and the way they interact.

Again this is another case where I wish I had of taken actual notes instead of just enjoying the talk, because then I would be able to say something more meaningful here other than “You should have been there.”

I’ve already thanked Damian above, but I suppose he should get two for doing two talks. Thanks Damian!

Conclusion

DDD is a fantastic community run event that doesn’t try to push any agenda other than “you can be better”, which is awesome. Sure it has sponsors, but they aren’t in your face all the time, and the focus really is on the talks. I’ve done my best to summarise how I felt about the talks that I attended above, but obviously its no substitute for attending them. I’ve linked to the slides or videos where possible, but not a lot is available just yet. SSW was recording a number of the talks I went too, so you might even see my bald head in the audience when they publish them (they haven’t published them yet).

I highly recommend that you attend any and all future DDD’s until the point whereby it collapses under the weight of its own awesomeness into some sort of singularity. At that stage you won’t have a choice any longer, because its educational pull will be so strong.

Might as well accept your fate ahead of time.