Fast forward to the present and I find myself reflecting on Ruby Conf AU, held on the Gold Coast recently.
My gut feeling is that the conference would score fairly well if evaluated against Kent’s criteria. But us programmers are analytic beings, so let me reflect on the talks and see how well they stack up.
Whilst there were many excellent talks amongst the 24 that were included, I’m going to pick some of them that resonated with me and place them each in one of Kent’s categories.
Gradual refactoring, as illustrated by Katrina Owen in her One Undo talk, is a vital aspect of working in small increments. Katrina showed us an example of how to initially place some poorly optimised code under test and then progressively improve it by teasing out the abstractions. To me, it was a brilliant example of how to “remove duplication and improve names in small cycles”, as Joe Rainsberger would say.
To work in small increments, refactoring as you go, requires effective testing strategies. To this end, Tom Ridge gave a thoughtful talk which focussed on the readability of RSpec code. In Explicit Tests Tell a Better Tale, he challenged us to consider how our choices in our RSpec usage affect our cognitive load.
I could have categorised the talk by Elle Meredith as honest, which undoubtedly it was. However, my first inclination about Elle’s talk entitled Feedback Matters was that it was foremost about being kind. As Elle’s talk emphasised, giving and receiving feedback in the right spirit with careful attention to how it affects people is of utmost importance to software development teams.
Ernie Miller struck a chord with his Humane Development – Empathy talk. I’m looking forward to seeing his slides and watching the video to see what else I can glean from what Ernie had to say. But I do recall that I found myself thinking, how good is it to hear someone talking about empathy in the context of software development!
Adam Cuppy may have posed the question, What If Shakespeare Wrote Ruby? and arguably provoked thoughts about abstract commonalities between Shakespearian and Ruby patterns. However, to me there were overriding factors that lead me to unquestionably consider his talk as kind. For one thing, this professionally trained actor provided the opportunity for the organisers to schedule his talk as the second last in the conference. A masterstroke! Secondly, Adam describes himself as a Master of Smile Generation. I rest my case.
Jeff Casimir opened the conference with a talk that unquestionably fitted the “honest” bill. Sharing his experiences in the context of 10 Years and 10 Mistakes set a nice tone for the conference. I found it to be a refreshing approach. We all learn from our mistakes but it takes a certain degree of intestinal fortitude to get up on stage and honestly talk about all the ways you have goofed up.
Debugging Diversity, presented by Dan Draper and Catherine Jones was without a doubt an honest appraisal of the challenges that face the Australian tech community with respect to increasing the opportunities for people who don’t fall into the “white male” stereotype that is predominant.
Given the seriousness of the diversity challenge in tech, it was pleasing to also listen to Jess Rudder give her perspective on the topic. Her presentation, Diversity in Tech – It’s About More than Just the Hiring Process, hit home, focussing on a critically important aspect. The fact that so many women choose to leave the IT industry points to a problem that the community needs to address.
We were privileged to hear Senator Scott Ludlam present the closing keynote of the conference. Honesty is a word that leaps out when I reflect on Scott’s talk, How the government broke the internet. The importance of an honest approach to the Internet and democracy, that is. As Scott illustrated, we certainly cannot assume government honesty when it comes to privacy for individuals and transparency of governments.
I guess it’s fair to say that Paulo Perrotta presented about “details”. After all, his talk delved into Refinements, a Ruby 2 feature. However, when you consider that Paulo’s talk was entitled Refinements – the Worst Feature You Ever Loved, you get an idea that this Italian has a devious sense of humour. And so it proved. To me, this was a great example of the importance of presenting a technical talk as an entertaining story.
When I reflected on what André Arko had to say, I admit that I hesitated about where to place his talk, or talks. His official talk was entitled Security Is Hard, But We Can’t Go Shopping, in which he shared with the audience the importance of handling security vulnerabilities. I guess it’s fair to say that’s an explanation of details. However, that wasn’t the end of his message. André went on to talk about Ruby Together, which to me sits squarely in the honesty category.
Of course, the talks were only part of the conference. I love the way RubyConf AU has evolved to feature plenty of social activities. My impression is that our international guests particularly appreciate these, especially those on the Saturday morning. Kudos to the conference organisers, Jo Cranford, Rob Jacoby and Trish Jacoby, together with the volunteers for their thoughtfulness and kindness.
I think my selection of talks bears out my contention that the success of Ruby Conf AU 2016 coincides with the fact that many of the talks fitted in with Kent’s idea that a good conference focusses on small increments, kindness and honesty.
Whilst Ed’s Functionally Oblivious and Succinct talk was undeniably impressive, it was his Stop Treading Water: Learning to Learn (download slides: 43MB) keynote which struck more of a chord with me.
I found the whole of Ed’s keynote fascinating. I love philosophical talks like this that provoke the listener into tangential thinking.
Ed drew upon a variety of references to shape what he had to say about how we can better learn. I liked his emphasis of the importance of revisiting something you have already learned, ideally when you’re just about to forget it, and improving your understanding by exploring the topic in more depth.
As a case in point, I’ve forgotten the details of what underpinned this point in Ed’s talk. Revisiting his slides, I now recall that he presented a hypothesis known as the forgetting curve which was developed by Hermann Ebbinghaus in 1885. Ebbinghaus showed that there is an exponential loss of memory unless information is reinforced. This leads to the idea of using the spaced repetition learning technique to achieve iterative deepening of knowledge.
Another aspect of Ed’s talk that struck a chord with me was when he spoke about the need to be careful with jargon.
To quote from his keynote:
If you use jargon, always be willing to explain what it means.
Ed reminisced about answering questions in maths exams at school when the answer was obvious to him. This brought back memories of my own. Why bother going through all the intermediate steps to show how the answer could be derived when you could work it out in your head?
Getting back to Ed’s talk, he also alluded to how the work of French Mathematician Jean-Pierre Serre was taken to a higher level of abstraction by Alexander Grothendieck. Whereas Serre presented brilliant yet concise proofs, Grothendieck was renowned for his mastery of explanation.
What Ed had to say about the benefits of explanation set me thinking about how this applies to activities in software development, especially within a team.
Here are some examples.
An aspect of the Agile approach to developing software has been the reaction against Big Design Up Front. However, in my humble opinion, this has often been an over-reaction.
Sure, it can be crippling to the flow of developing software to spend a lot of time designing before writing code.
However, taking the time and putting in the effort to explain your intended design early can reap dividends. It may simply involve a small group of people discussing some rough design diagrams on a whiteboard. Or it may be an asynchronous discussion, perhaps including sketched diagrams, in a GitHub pull request2. Explaining a design idea to your colleagues can often save much time and effort if it reveals a better approach before significant time and effort has been invested in coding and testing.
Spreading knowledge throughout a software development team is, in my experience, more important than often fully appreciated.
In the day to day work towards delivering new features and getting the things done that the business needs done, one thing that can get left behind is the effective transfer of knowledge about the domain and how applications and technologies support the domain.
A potential antidote to this effect is for more deliberate effort to be put into explaining various aspects of what members of the software development team are doing.
Where it is recognised that one developer is the only team member with a thorough understanding of one critical system, sub-system or technology, a lunch-time talk could provide the opportunity for others to learn from the expert developer’s explanation. Alternatively, details of an approach to developing a feature could be elaborated on within a GitHub PR. Or perhaps explanation could be provided in an online question and answer discussion within whichever online communication tool the team is using.
The important thing is the preparedness of everyone in the team to share their knowledge for the good of the team as a whole.
A third example of the benefits of explanation in the context of programming, and one of my favourites, is what I refer to as explanatory debugging.
Have you ever found yourself stuck when trying to debug a software problem? I know I have on many an occasion.
At times like this when I have swallowed my pride and asked for a colleague to help, what happens next can be uncanny. Once I have their attention, I begin to show my colleague the code and explain the problem to them. It’s amazing how many times I don’t even get to finish explaining the issue before I see the source of the problem. To me, this scenario is one of the most powerful examples of how pair programming can work well. The simple act of explaining the problem so often quickly leads to a resolution.
In a nutshell, being prepared to explain your reasoning is powerful. If you consider your reasoning to be important, taking the time and effort to share it will most likely lead to a better shared outcome.
And, on that note, I would like to thank Ed Kmett again for his thought-provoking keynote!
1 Many thanks to YOW! for permission to reuse this photo.
2 I intend to say more about effectively using Github PRs in another post soon.
My motivation for giving the talk was to share some ideas about how to learn to love legacy code more.
Rather than going into a detailed outline of what I spoke about, let me say that, in essence, I was encouraging developers and managers to approach the challenge of working with legacy code with helpful techniques and a good attitude.
Along the way I spoke about how to identify pain points, effective testing, refactoring towards simple design and tool support to help the fallible brains of developers.
But I guess I wanted the main takeaway message to be this:
Respecting the people who have been involved with, those who are currently working with and those who will in the future be affected by the codebase will make you feel better about the code.
Hopefully the ideas I shared provoked some in the audience to think more about how they might enjoy and gain satisfaction from the challenges of working with legacy code.
Unsurprisingly, the ideas presented weren’t all original!
So the main point of this post is to acknowledge those who have inspired and helped me and to provide links to resources that I drew upon for the talk.
I would especially like to thank and acknowledge my colleagues at Blake eLearning, especially Dan, Dave, Josh, Lachie and Martin, who did me the honour of listening to me practice my talk and gave valuable feedback. I would particularly like to thank Navin, who generously shared both his viewpoint about some specific legacy code and some more general insights.
I am continually grateful to those who have taken the time to write about issues relating to working with legacy code. Here are a few resources that I drew upon for my talk.
I’ve enjoyed the conversations that have been prompted by my talk so far. Hopefully they will inspire me to write and talk more about specific aspects of working with legacy code.
And, of course, improve my own capacity to love legacy code more.
The time is getting closer.
It has been a while since I spoke at a conference and, even though I have since spoken at many user group meetings and other tech events such as Rails Camp, I am very conscious of the need to improve.
The point of this post is to acknowledge how much I am appreciating the wonderful speaking.io site that Zach Holman has curated. I recall seeing Zach speak at YOW! a few years ago and marvelling at his seemingly effortless delivery. Now I am very grateful for the tips that Zach has provided. Hopefully I’ll do them justice.
For now, if you need to prepare a talk, I thoroughly recommend Zach’s speaking.io site.
I’d better get back to my slides.
“That’s wrong!”, interjected a member of the audience.
I was taken aback. I had suggested the following definition of the Single Responsibility Principle.
“A class should do the smallest possible thing; that is, it should have a single responsibility.”
At the time, all I could respond with was: “well, that’s one definition”. In fact, this quote was taken verbatim from Practical Objected-Oriented Design in Ruby by Sandi Metz. The purpose of my talk was to use Sandi’s excellent book to generate discussion about better OO design in Rails applications. Fortunately for me, those present at the Sydney Ruby meetup (or “rorosyd” as it is affectionately known) responded well and all ended well.
However, the experience left me pondering.
Kevlin is an Englishman who delights in the proper use of the English language. Very early in his talk he questioned the use of the word principle in relation to SOLID design. Kevlin suggested that the word pattern was more accurate. As he illustrated his point by referring to the Oxford English dictionary, it was hard to mount an argument against his criticism.
Focussing on the so-called Single Responsibility Principle, Kevlin started with the Wikipedia entry. After all, it appears first in a Google search and how could it possibly be wrong? Interestingly, the entry is both potentially misleading and illuminating. It defines SRP thus:
“Every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.”
This is not so different to Sandi’s definition. However, the same Wikipedia entry also notes that Robert C. Martin introduced the term, going on to say that:
“Martin described it as being based on the principle of cohesion, as described by Tom DeMarco in his book Structured Analysis and Systems Specification.”
Here is where an exploration of the language behind the description of SRP gets interesting. Kevlin referred to Glenn Vanderburg’s article on cohesion. Glenn relates that he has had most success in explaining the term cohesion in terms of it’s etymology. In short, cohesive things belong together as opposed to those that need an adhesive to glue them together.
Bearing this in mind, let’s read what Robert C. Martin says in 97 Things Every Programmer Should Know:
“One of the most foundational principles of good design is:
Gather together those things that change for the same reason, and separate those things that change for different reasons.
This principle is often known as the single responsibility principle, or SRP. In short, it says that a subsystem, module, class, or even function, should not have more than one reason to change."
In other words, responsibility is equated to having only one reason to change. As someone else present at my rorosyd talk said in response to the first interjection, “it depends what you mean by responsibility”. Reflecting on the language used, however, leaves me thinking that the term “single responsibility” is not as helpful as the word “cohesion” when discussing good software design.
The whole of Kevlin’s talk was both thought-provoking and entertaining. He concluded by suggesting five alternatives for the SOLID principles that all begin with the letter C. In the place of SRP as the first “pattern” was Cohesion by Usage.
Kevlin’s talk has caused me to reflect on the importance of language in the context of software design.
What have I learned?
It also occurs to me that we need to guard against the increasing tendency in this day and age to only read short chunks of text. TL;DR is no excuse for those striving to be better developers.
In closing, if you’ve read this far, I’ll leave you with a recommendation. If you ever get the chance to see and hear Kevlin Henney talk about software, grab it with both hands.
We are on the home stretch!
Just over a year ago I made a commitment to ensure that the inaugural Australian Ruby programming conference would become a reality. Next week, in Melbourne, it will.
RubyConf Australia 2013 will kick off with a day of workshops on Wednesday before more than 350 delegates gather at the conference to hear speakers present a variety of Ruby-related talks on Thursday and Friday.
With less than a week to go, you may wonder why I have chosen to devote time to a blog post now. You’d think I would be flat out doing last minute things in preparation. Of course I am, but I guess I thought it would be therapeutic to spend a few minutes sharing my reflections about organising the conference.
I won’t go into exhaustive detail now but I do want to emphasise several factors which have underpinned the conference organisation. Without them, I doubt we would have got to where we are today without much more pain.
That’s it for now. I’m not sure how insightful that was for you. It was somewhat cathartic for me but not as helpful as the drinks at the conference closing party will be.
Wish us luck!
Perhaps I needed time to reflect on such a wonderful conference.
Ever since the YOW! Developer Conference in Melbourne last December, I’ve been meaning to share some of my impressions. It may be three months down the track but I’m finally getting around to it!
The conference deserved praise for many reasons but I’ll narrow it down to some brief reflections on five talks that impressed me for different reasons.
A small percentage of Rails developers have the opportunity to work in teams developing large, enterprise-scale apps. A not insignificant number of aspersions have been levelled at Rails, claiming that it can’t scale. So it was refreshing to hear Neal Ford talk about Rails in the Large, based on his experiences leading a team that has built arguably the biggest Rails app in the world.
Neal’s invigorating talk reviewed the lessons learned in the project such as effective testing strategies. For example, he unsurprisingly impressed the audience by relating how, with the help of UnitRecord, the team was able to run just under 9,000 tests in 41 seconds! Neal described other testing techniques as well as strategies for aspects such as continuous integration, effective communication in a development team and automation. Crucially, he emphasised ingenious ways that the team kept a sense of fun to the fore at all times.
There were many more nuggets that this talk contained. If you get the chance to hear Neal speak I thoroughly recommend it.
I cannot find the words to adequately describe the gem that was the 50 in 50 keynote by Guy Steele and Richard Gabriel.
So I’ll keep my reflections brief. Wise, well-informed and witty, this talk by Guy and Richard was rich in its perspective of the often weird and wonderful paths that computer languages have followed over the last 50 years. A perfect tonic to prepare us for the conference party!
Getting a message across through dry humour is a gift which Eric Evans demonstrated amply in his talk entitled Strategic Design: Avoiding Responsibility Traps.
Eric led the audience through a story about several sub-optimal scenarios that can eventuate when a software development team is faced with the challenge of augmenting a legacy system. His key messages included the importance of distilling the core domain, using context mapping and building an anti-corruption layer. Eric’s parting recommendations were to:
And, of course, to make use of his book, Domain-Driven Design, even if only to read Chapter 14.
I love the tagline on Jason Yip’s blog: “Making software is about making people.” So true.
Jason’s talk, Row Together, Row in the Right Direction, Row Faster: Improving alignment and throughput in software development, tuned into vital aspects of collaboration, whether at the level of a team, department or organisation.
After setting the stage with a few amusing but relevant anecdotes, Jason expanded on his contention that groups of people maximise their collective effectiveness by:
Jason emphasised that what he had presented was intended to be more of a useful metaphor than the result of rigorous analysis. It would be interesting to see Jason’s observations validated by quantitative research. Meanwhile, I’m glad I listened to Jason’s typically thoughtful, entertaining and thought-provoking talk.
As someone who, when first exploring object-oriented programming cut his teeth on Smalltalk, I was fortunatate to be able to listen to Dan Ingalls reminisce about his Forty Years of Fun with Computers.
It was amazing to listen to Dan speak so humbly about his experiences when they included working with Alan Kay and attending lectures given by Don Knuth, not to mention being the principal architect of five generations of Smalltalk environments. Regardless of all his achievements what shone through above all was his enduring sense of fun. I won’t attempt to describe the specifics of Dan’s talk. Suffice to say it was a privilege to be there and a special way to end the conference. If you get the chance to hear Dan speak, grasp it!
Dan concluded his talk with this wonderful advice:
“Keep things simple, general and flexible and you’ll have fun.”
So there you have it. Five of my favourite talks from the YOW! Australia 2010 Developer Conference.
Belated congratulations to Dave Thomas and Lisa Cumes from Bedarra Research Labs for attracting such a superb collection of speakers covering a broad range of topics. The whole conference was a blast and I certainly wholeheartedly recommend the 2011 edition to other Australian developers.
Thanks to Dave Thomas the JAOO conference was recently held Sydney again. As he was introducing himself before his talk about Application Development and Deployment in the Cloud, Dave remarked that “he was responsible for all the bad things about JAOO”. Not much fell into this category and I’m sure Dave was responsible for many of the good things, such as attracting many excellent speakers.
As expected Dave demonstrated his vast knowledge of software and gave me much to ponder concerning likely trends over the coming years.
Among other talks that inspired me at JAOO were both Avi Bryant’s talks, especially his “Speeding Ducks” talk about how it is possible to improve Ruby’s speed through the use of techniques such as native code generation and inline caching. Patrick Lindsay’s title for his iPhone dev talk was, as he would freely admit, somewhat misleading. He did cheat a little to enable him to finish building his app within 45 minutes! Glenn Vanderburg’s talk about Fuzz Testing has encouraged me to give Tarantula a try.
So far I’ve given a few examples of technical talks at JAOO that I valued. The presentation that inspired me the most was one by Linda Rising entitled “Hardwired for deception means trouble with estimates!” Linda built up her argument by providing examples of studies that have shown how we “naturally deceive ourselves and others – constantly”. Linda left it until the end of her talk to relate these findings back to software development but by then the message should have been clear to anyone who was prepared to accept the evidence:
“A strong tendency to ignore previous feedback and persist in overconfidence in their own estimates have been observed in software development.”
As Linda concluded, the only sensible way out is to follow an Agile approach that uses small steps, experimentation, a preparedness to learn from both success and failure, involves others and incorporates retrospectives and openness.
I love learning technical stuff about software development but always find it refreshing to hear people-focussed talks from experienced practitioners like Linda Rising.
The fifth Australian Open Source Developers’ Conference was held last week in Sydney. In addition to helping organise the conference, I was fortunate enough to be one of the Ruby presenters.
Naturally, these slides were designed to assist my presentation rather than contain all the content. Indeed, the inclusion of some of the slides may beg some questions so I thought it may be helpful to add some explanation here.
Each of us programmers is on a specific journey, especially when it comes to testing. Early in my professional career I was taught how to unit test program modules written in PL/I. However, the drivers for those tests had to be written in Job Control Language (JCL) – an experience I am not in a hurry to repeat.
Many years later, having escaped from working on mainframes, I discovered JUnit. This was a fundamental tool in my early experience of test driven development and refactoring. When I began exploring Ruby and Rails, I was eventually introduced to autotest, which I considered another quantum leap forward in the realm of automated testing.
In 25 minutes there was obviously a limit to the number of Ruby testing tools I could cover. So, having quickly explained the benefit of autotest and touched upon Test::Unit, I moved on to describe some tools that I have used in the last year.
To make sure the audience was still awake, at this point I showed a cute photo of our family dog. My lame excuse was that he exhibits a wide range of behaviours and RSpec is all about specifying behaviour. My main example of using RSpec was for specifying a controller. This led on to a brief digression into consider what makes a good test and the use of mock objects to isolate unit tests and make them faster by avoiding unnecessary database I/O.
I was pleased to be able to include Cucumber, Webrat and Selenium in my talk. It’s only fairly recently that I started using Cucumber in conjunction with Webrat or Selenium and I’m impressed. As Mike Koukoullis showed in his subsequent talk, developing with Cucumber is a very powerful approach, which fosters clear description of intent before development of any feature.
Speaking of other talks, Alister Scott used a lightning talk to share his enthusiasm for Watir, which looks like a good alternative to Selenium.
After briefly relating the motivation for developing alternatives to relying on fixtures for test data, I described Machinist, an elegant tool recently developed by Pete Yandell. When used in conjunction with Sham, Machinist provides a neat way of generating “blueprints” that can be used in Cucumber steps.
To round out my talk, I thought it was important to offer a few philosophical thoughts. In a nutshell my view is that, whilst it is important to remember that automated testing is just one of many error removal approaches, we can all benefit from investing in automated testing.
In my case, as well as practicing using these tools, I’m also looking forward to reading the upcoming title The RSpec Book by David Chelimsky and others.