Keith Pitty

Reflecting on My Retrospectives Journey

2021-08-09T21:12:54+10:00

The Initial Inspiration

It must be getting on to a decade ago now.

I had been freelancing, doing Ruby on Rails development for Blake eLearning for a few years. The size of the team had grown significantly since I started contributing.

Thinking further back, I had been a keen practitioner of all things Agile since 2001. My colleagues and I at an Enterprise Java consultancy had been early practitioners of eXtreme Programming. We were keen to learn more about the meeting of minds that led to the Agile Manifesto.

So, it was in about 2013 when I started reading Agile Retrospectives by Esther Derby and Diana Larsen that I suggested to the Blake Tech Lead, Martin Stannard, that retrospectives would be beneficial to the team.

My Journey

Using Trello

At some point we had adopted Trello as our tool of choice for tracking our work. So, when we began holding retrospectives, it seemed natural to use Trello to capture the discussion points for each retro. After all, Trello is an adaptable tool, and it enables remote participation.

Regardless of the tool, my recollection is that adopting the practice of holding regular retros significantly helped our teamwork at Blake. We may not have been as sophisticated as Esther or Diana. Nevertheless, the simple opportunity for the team to gather and reflect on our recent work, and for each member to have their say, was powerful.

A lo-fi approach

In mid 2015 I moved on to work at The Conversation. I spent the first week on site, in Melbourne. At the end of that week, as was the usual practice on a Friday, the team held a retrospective.

It was definitely lo-fi. The tools to support the discussion were a whiteboard and coloured markers. The board was divided into quadrants to guide the team’s focus on what had gone well, what hadn’t gone so well, what questions had arisen and what actions should be taken. At the end of the retro a mobile phone was used to take a photo of the board. That photo was then emailed to the team. It was a practice that had so far stood the test of time.

At this point I should emphasise that I had joined the team as it’s first remote member. So, at the end of the next week when I was back in my home office, an obvious challenge surfaced. I had no visibility of the retro board until after the retro had concluded! As the weeks went by I suggested that we consider using Trello. However, there was resistance, probably because the simplicity of the quadrants on the board had worked so well for the team for so long.

RemoteRetro is born

Months went by. In February of 2016 the team was at the Gold Coast in Queensland for the fourth edition of RubyConf AU. One of my colleagues, Mark Cipolla, had been thinking about my inability to participate in the retros as fully as the rest of the team.

Thankfully for me, this thought led to action! During those few days on the Gold Coast, Mark started developing a web application that mimicked the team’s retro white board. Sure, in it’s initial form the tool was somewhat rough around the edges. But it solved my problem!

From then on, using RemoteRetro, everyone in our team was able to add items to the retro board via a web browser. Mark quickly added a feature to allow voting so that the team could give more focus to discussing the issues that most people cared about.

For some time RemoteRetro was just used by the development team within The Conversation.

Meanwhile, Mark kindly invited me to join him as a co-founder of this side-project. We worked on it at a Rails Camp in the Gold Coast hinterland, ironing out some bugs and gave a demo of RemoteRetro on the last night. I guess that was one way other development teams came to learn about the potential to use RemoteRetro in their team retros.

At another Rails Camp in late 2017, we added some polish to RemoteRetro so that users could actually sign in and, for example, see boards for previous retros from within the tool. This was a significant weekend that saw us take the product towards a level where it may justify paying customers.

A demand to pay for RemoteRetro

As you can see from the tweet above, by March 2018 we were getting some encouraging feedback from other users of what was still a free product.

Not only that, Myles quite rightly pointed out that users should have the opportunity to pay for RemoteRetro!

So, Mark and I set about enabling others to pay for using what for a couple of years had been a free product.

Subscriptions launched

As has been the case for most of RemoteRetro’s history, Mark did the bulk of the work on the codebase to pave the way for subscriptions to be introduced. However, I do recall that during a trip to Melbourne to watch a couple of games of footy and catch up with friends and family, I spent a few hours with Mark that culminated in us launching a version of RemoteRetro that allowed users to subscribe.

Yes, after a period of more than two years during which the tool had been free to use, we had enabled Myles and others to “throw us some dollars” in exchange for using RemoteRetro!

Happily for us, despite it having a small user base, RemoteRetro is now used by teams all over the globe.

We are aware that there is scope for improving the product. However, we also continue to guard against the tool becoming unnecessarily complex as a result of feature bloat. Having said that, if you’ve given RemoteRetro a try and have some suggestions about how it would better serve your team, feedback is always welcome.

More experience with retros

In 2018 I introduced retrospectives to the development team at Birdsnest. Looking back on that time, I must admit that there were times when I struggled to maintain my composure, sometimes during a retrospective. I am grateful to a colleague for reminding me of the Prime Directive. Originally emphasised by Norm Kerth, it states:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Reflecting on this fundamental perspective can be humbling.

Later, after I had moved on to Clover in mid-2019, our teams benefited from using different formats of retrospectives. By this time RemoteRetro had been adapted to support alternatives such as Start/Stop/Continue and Mad/Sad/Glad, as well as the ability to create custom formats.

Why I love retrospectives

From very early years in my life I’ve enjoyed teamwork. I guess it stems originally from the experiences I had playing team sports. As the years went by I accumulated other types of teamwork, at school, university and in the workplace.

A core facet of teamwork is ensuring that every member of the team feels empowered to have their say.

That’s why I love retrospectives. As the saying goes, a team is greater than the sum of its parts. Retrospectives are a powerful tool for drawing upon the thoughts and feelings of all members of a team in a constructive way.

Learning from the masters

Unsurprisingly, I still feel that I have much to learn about retrospectives.

Several years ago, at a YOW! conference, I recall hearing Aino Vonge Corry speak passionately about retrospectives. She has accumulated much experience in facilitating them, to the extent that she has published a comprehensive book of retrospective antipatterns. I’m still digesting them but based on what I have read so far, I thoroughly recommend adding Aino’s book to the one by Esther and Diana that originally inspired me.

Looking ahead

If you’ve read this far, you may have developed the impression that this post is a thinly-masked plug for RemoteRetro. I guess that’s partly true.

But only partly.

As I discovered last year when facilitating a discussion about remote retrospectives, there’s a range of tools that teams are using whilst conducting retrospectives online, now that the pandemic has resulted in team members working from home.

With an eye to the future, I’m fortunate to be looking forward to participating in retros on a regular basis, and learning more about how to make the most of them.

Enabling Application Longevity

2021-04-18T22:34:43+10:00

The following tweet recently captured my attention:

It has obviously struck a chord with many others because it highlights a truism in software development. So many applications become burdened with being cumbersome to maintain because insufficient priority has been given to enabling them to be tested within a practical time-frame.

More on this theme

This is a theme that was also highlighted recently in an article in the Australian Computer Society’s Information Age entitled Software testing is slowing transformation. This article cited a report by Tricentis that found that the average time software testers spent manually checking “the functioning of every element to ensure that the quality and reliability of the whole solution have been maintained” is now taking an average of 23 days.

Obviously the reliance on manual quality assurance testing does not enable quick development and deployment of changes to applications.

Unsurprisingly, the Information Age article goes on to emphasise the importance of automated testing.

“Automated software testing has emerged as a key tool to make this happen, with increasingly intelligent, AI-driven tools able to source human-written source code for changes, dependencies, and even potential security issues.

Few companies are achieving the greater than 75 per cent automation rate that signifies mature software development processes, the report notes, while most lack supporting testing technology like service virtualisation and test data management."

So What?

What’s the point of this post? Essentially, I want to draw attention to the cost of maintaining an application. As has been acknowledged many times previously, the cost of maintaining an application is many times the cost of its initial development.

Once an application has first been deployed to production, if it is to stand a chance of being successful into the future, careful consideration needs to be given to how to enable it to be maintained in a sustainable fashion.

When do we need to consider application longevity?

Before it is too late!

If we observe what Ward Cunningham’s original wiki had to say about Technical Debt, one of the key statements was:

“Don’t let the debt build up. Everyone knows the list will never be addressed. Remove cruft as you go. Build simplicity and clarity in from the beginning, and never relent in keeping them in.”

So, as a development team, in conjunction with the business, we need to deliberately focus on enabling application longevity from early in the piece. The longer we leave it, the harder it will be to recover the technical debt.

Too often, this lesson is ignored.

What will enable an application to last and thrive?

Automated tests

As the earlier tweet and ACS article emphasised, an absence of automated testing inevitably leads to a dependence on lengthy, manual testing. Given the fact that automated testing and continuous integration have been long-standing practices, there is no excuse for bypassing them.

The alternative is, whichever way you consider it, a significant impediment.

In one scenario, the team is faced with time-consuming, error-prone manual testing whenever a change is to be considered for deployment. Or, worse still, changes that would otherwise improve the internal design of the application or improve its business function, are not delivered at all due to a lack of confidence that the application will not break.

There will be circumstances when years pass and the application has not been given the benefit of automated tests. If this is the case, it may not be too late. A decision can still be made to start building automated tests and a CI infrastructure. However, this is likely to require significant persuasion that the investment is worth it.

A commitment to refactoring

Before I go any further, let me be clear. Refactoring implies automated testing. Too often I have heard developers talk about their intention to “refactor” a part of a codebase when there are no automated tests. As Martin Fowler put it in the subtitle of his Refactoring book back in 2000, it is Improving the Design of Existing Code.

Automated tests are required to ensure that the behaviour of the existing code remains the same as the internal design is improved.

Having made that point, it is important to recognise that a codebase is liable to decay over time. Quick fixes can be applied without concern for long-term maintainability. Developers new to a codebase can solve problems without adhering to patterns already established in the codebase. Many other factors can lead to code that is not easy to maintain.

So, especially when a part of the codebase is being changed to add a business feature, care should be taken to refactor, to improve the design of existing code.

A commitment to updating dependencies

When an application is first launched, it is likely to depend upon recent versions of the operating system, database management system, web server, web framework, programming language and various open source libraries. It is also likely that, at this time, very little attention is paid to the fact that the versions of these dependent software systems and libraries are recent.

Shortly after the time when an application is first launched, how much attention is paid to a maintenance plan? Probably not much. The business is likely to be more focused on how well the application will achieve its objectives. This is reasonable.

However, at some point, as it hopefully becomes clear that the application is achieving sufficient success to remain deployed for the foreseeable future, attention must be paid to updating dependencies. Tools such as Dependabot smooth the way.

Failure to embark upon a program of regularly implementing updates will lead to a poor set of outcomes. As far as ease of maintenance is concerned, allowing versions of dependent software to get out of date is likely to result in much time lost in frustrating developer experience, whether it is due to difficulty in installing unsupported versions or a mismatch in online documentation and old versions that the application still depends upon.

The lack of security patches, which are regularly included on new versions of software, can also result in risks to business operations.

Relating these comments back to the tweet reference that started this post, a healthy set of automated tests will make it much easier to confidently apply updates of dependent software. A lack of automated tests and CI will likely lead to dependence on unsupported software. As a related aside, it is interesting to read the first two paragraphs of Upgrading Ruby on Rails on the Rails Guides site:

“Before attempting to upgrade an existing application, you should be sure you have a good reason to upgrade. You need to balance several factors: the need for new features, the increasing difficulty of finding support for old code, and your available time and skills, to name a few.

The best way to be sure that your application still works after upgrading is to have good test coverage before you start the process. If you don’t have automated tests that exercise the bulk of your application, you’ll need to spend time manually exercising all the parts that have changed. In the case of a Rails upgrade, that will mean every single piece of functionality in the application. Do yourself a favor and make sure your test coverage is good before you start an upgrade."

Parting thoughts

A successful application launch is something to be celebrated. An application successfully operating after a significant period of time is even better. However, careful planning and management are necessary to ensure that applications truly stand the test of time.

Automated tests and continuous integration play a crucial role in allowing development teams to confidently maintain applications that will continue to adapt to changing business requirements.

Recent Reading

2021-02-17T07:16:27+11:00

It has been a while since I wrote a post on this site. I have a few ideas for topics to write about in the future but I shall let them percolate for the time being.

Meanwhile, I thought I would write a brief post to share what I have been reading lately that relates to my work.

Photo by Susan Yin on Unsplash

General

Retrospective Antipatterns

By Aino Vonge Corry

Aino is a long-time facilitator of retrospectives. Whilst she hails from Denmark, I recall hearing her speak at a YOW! conference in Sydney several years ago.

As someone who has facilitated and participated in retrospectives for many years, I’m keen to learn how to make them more effective. So I’m grateful to Aino for sharing the knowledge she has gained from her experience.

Somewhat ironically, Retrospective Antipatterns is arranged in a pattern. Aino presents 24 antipatterns, divided into three parts: structural, planning and people. Each part contains eight antipatterns. Is it a coincidence that there is a picture of an octopus on the cover of the book?

Anyway, I’ve read the first three chapters and am keen to work my way through the remainder of the book. Unfortunately I haven’t had the opportunity to be involved in any retrospectives for a while but hopefully that will change soon.

The Culture Code

By Daniel Coyle

Whilst I haven’t read Daniel Coyle’s The Talent Code, I recall hearing it recommended in a conference talk a few years ago. So, when I was curious to find a good book about what makes for a successful organisation, I was attracted to reading what Daniel had to say about culture.

Throughout my career as a software developer, which now spans 37 years, I have firmly been of the opinion that people are more challenging than technology. Moreover, I have thrived when I’ve worked within a well-functioning team. However, that has not always been the case. I can recall some stages in my career where, to me, there were significant problems with the organisation’s culture.

Daniel lays out advice about how a group can develop three crucial skills: building safety, sharing vulnerability and establishing purpose. I’ve nearly finished reading the chapters in the first section and am impressed by what I have read so far. Once I’ve finished the book, I anticipate delving back into it to refresh my memory on Daniel’s advice about building a healthy culture. It’s a vital topic for any workplace.

Succeeding with OKRs in Agile

By Allan Kelly

We’ve been attempting to use Objectives and Key Results at work recently. I must admit I have been somewhat skeptical about how effective they have been. However, a few days ago I became aware of this book, which has been recently published in electronic form.

Having read Allan’s books Project Myopia and Continuous Digital, I was interested to learn that he had been moved to write a book about OKRs. I’ve only just started reading it but, knowing that it is based on Allan’s experience of how to create and deliver OKRs, I’m interested to read the rest of the book. Maybe then I’ll be more convinced of how helpful OKRs can be.

Technical

Elixir in Action, Second Edition

By Saša Jurić

I’ve been maintaining and enhancing an Elixir application at work for the last 18 months or so.

As I have built my knowledge about the application I have also found myself needing to delve into understanding the fundamentals of Elixir. This has been over and above understanding how Elixir implements functional programming. When needing to become more acquainted with the intricacies of Elixir’s GenServers, supervisors and fault-tolerance, for example, Elixir in Action has been an invaluable resource.

Adopting Elixir

By Ben Marx, José Valim and Bruce Tate

Whilst I haven’t got far into this book, I am sure that it is contains much good advice. The authors of Adopting Elixir, published in 2018, wrote the book to share their experiences and provide details “that are typically difficult to find for an emerging language”.

The book is divided into three parts, following adoption from concept to development and, finally, to production. I’ve been dipping into different chapters in the book, mostly concerned with production. Despite the fact that it’s three years since this book was written, I’m finding it valuable. For example, given that we are in the process of shifting the deployment platform for our application from Heroku to AWS, the book provides helpful explanations of the details of how a release is built, how the application is configured, and how it can be deployed using blue-green deployments.

Craft GraphQL APIs in Elixir with Absinthe

By Bruce Williams and Ben Wilson

Not so long ago at work I needed to develop a Proof of Concept API in our Elixir application. Given that we have used GraphQL elsewhere in our platform, I chose to develop an Elixir GraphQL API. This book proved to be extremely helpful.

Whilst the book goes into more detail than I needed, I appreciated how it guided me through the process of creating a schema module and a GraphQL query so that I could then demonstrate the API via GraphiQL.

In Closing

So there you have it. I’ve always valued reading books as a way of learning and this post gives you, dear reader, an idea of what I’ve been reading lately.

Succeeding with Remote Retrospectives

2020-10-08T21:51:30+11:00

Obviously 2020 has been a challenging year all round.

In particular, when work groups meet to reflect on their recent work, now that these retrospectives are taking place virtually, extra challenges present themselves.

Recently, as part of the mini-LAST #2 conference, I presented what was partly some of my suggestions and partly a facilitation of discussions about succeeding with remote retrospectives. I promised to share the outcomes. Hence this blog post.

Motivation

The first of three aspects that I covered was a fundamental one. Remote or in person, why would a team want to hold a retrospective anyway?

Share recent successes

In my view a good, positive reason to hold a retrospective is to reflect on recent successes. I recall occasions in my career when, at the end of a project, the team celebrated with a lunch paid for by the company. In these times of more iterative software development, I think it’s healthy to regularly celebrate recent achievements as a team. This can be done as part of a retrospective and helps to build team morale.

Reduce frustration

As well as sharing reflections on things that went well, a key motivation to hold a retrospective may to allow team members to voice their views about sub-optimal experiences. Providing a forum in which to let people to get things “off their chest” is important so that negativity does not build.

Emphasise the Prime Directive

Whilst I think it’s useful to allow people to comment on negative aspects of their recent work, it’s important that the team approach the retrospective in good spirit. This is reflected in what Norm Kerth proposed as the Prime Directive:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

So, it’s not a witch hunt! A healthy retrospective needs to acknowledge this as a premise.

Discuss questions

During the last iteration, sprint or whatever name your team has given to the period of time which you are reflecting upon, questions may have arisen. Encouraging team members to share uncertainties may lead to fruitful discussion, perhaps resulting in answers or actions that can lead to improvement.

Ideas from the audience

Having presented a few of my suggestions, I opened up discussion to seek more ideas from the audience about motivations for holding retrospectives. These included:

to improve;
because it’s expected by management;
to build team rapport;
to bond as a team

The second suggestion was somewhat cynical but nevertheless important to recognise. Unless there is genuine desire from the team to engage in a retrospective, it’s less likely to result in positive outcomes like improving teamwork.

Remote Challenges

Unsurprisingly the major aspect of my talk was to consider the challenges to holding a retrospective remotely.

Equal participation

It’s important that each person participating in the retrospective feels that they are getting a fair go. In a remote retrospective this implies that each person participates via their own video connection.

Before the onset of COVID-19 I can recall many retrospectives in which I was the only remote participant. Depending on the camera position in the room where everyone else was, this was at times quite disconcerting. Many times I felt like an outsider, having to say “excuse me” when I wanted to get a word in. And then everyone else looked at the camera. Contrast this everyone connecting with their own video camera as is more likely to be the case now that everyone is working from home.

Happily, I can also recall being part of retrospectives where I was the only remote participant and the co-located participants each took their laptop to a different part of the office and connected as if they were remote. It’s easy enough to do but, in my view, a very important step.

Audio and video

As with any online meeting, it helps to ensure that audio and video technology is working well. Invest in good microphones, make sure your software is configured to use them and prefer ethernet to wifi connections. Simple attention to these details will enable you to communicate seamlessly. For example, I know that in my home office the wifi connection in my office is not sufficient for smooth video.

Another simple tip is to set up your computer so that the camera is at a good height to enable others to see you at a natural angle.

Do everything you can to avoid distractions from good verbal and visual communication.

Retro tool

In a retrospective where everyone’s in the same physical room, a white board and post-it notes can be used.

When at least one participant is remote, this low fidelity approach breaks down. An online tool is needed. Whilst general purpose tools can be used, I favour one that is built for the purpose.

A couple of months ago this tweet posed a question about which remote retro tool people preferred. Now at this point I need to disclose that I am a co-founder of one of the tools mentioned, RemoteRetro. How I came to be a co-founder of this tool is another story, which I may make the subject of another post.

Suffice to say, to enable everyone to equally participate in a remote retrospective, you’ll need to choose one or more tools for online collaboration.

Facilitation

Facilitation is even more important when participants are remote. The facilitator will need to guide the team’s use of the retro tool as well as communicate effectively with participants via the video tool.

Variety

What format will the retro take? Don’t allow retros to become boring by choosing the same format each time.

For example, RemoteRetro, as well as allowing custom formats to be created, offers four pre-set formats:

Good/Bad/Actions/Questions
Start/Stop/Continue
Mad/Sad/Glad
Liked/Learned/Loathed/Longed For

Share ideas

In order to promote useful discussion the facilitator will need to encourage all participants to contribute ideas via the retro tool.

Facilitate discussion

Once ideas have been shared via the retro tool, at the very lest the facilitator needs to guide the resulting discussion.

Ideas from the audience

When we further discussed remote challenges as a group, the following ideas were generated:

make sure that genuine variety occurs, not just different formats or recipes
changing the focus of each retrospective can help
we need to follow up ideas that require action
a live, anonymous, interactive polling tool called Mentimeter was recommended to collect views from the team
other retro tools that were recommended included Metro Retro, FunRetro and RetroBoard
general purpose tools that audience members use for retros included MURAL and Miro

Enabling Improvement

To round out this presentation and discussion, I wanted to focus on improvement. Quite simply, if a retrospective doesn’t result in improvements for the team, it’s hard to justify holding it in the first place.

Note action items

Capture suggestions for actions arising from the discussion.

Use your chosen tool(s) to note action items and agree on who should be assigned to them.

Support for tracking action items

It’s important that action items are completed before the next retrospective. Otherwise, the team can become demotivated. They may start questioning the point of holding retrospectives in the first place.

A combination of using tools well and personal as well as team commitment to following through must support good intentions.

Ideas from the audience

Some ideas about enabling improvement that the audience suggested were:

don’t hold retros at 4pm on a Friday!
commit to realistic actions so that improvement has more chance of resulting
use the Heart of Agile as a prism for enabling improvement
use a Futurespective approach

In Conclusion

I would like to thank all who were involved in the mini-LAST #2 online conference, especially Ed Wong for enabling me to present. To those who listened and participated, a big thank you for what you contributed. Even though I’ve been an enthusiastic participant and facilitator of remote retrospectives for quite a few years, I know I still have plenty to learn.

Postscript

Speaking of having plenty to learn, this morning I was alerted to the fact that Aino Vonge Corry’s Retrospectives Antipatterns book was available. Having anticipated it for some time, I quickly took the opportunity to purchase it and start reading it. I’m sure that there will be many nuggets therein from which I can improve my own facilitation of retrospectives.

On Working Remotely

2020-05-06T23:17:14+10:00

The COVID-19 pandemic has obviously brought remote working into focus. Many meetups have also been forced to move to use online mediums. Of interest to me is that this month’s Sydney Rorosyd meetup will focus on how COVID-19 has affected workers.

The meetup will include an interactive forum about “issues, opportunities, and challenges during the pandemic”.

Some of the questions to be discussed will include:

What do you do to socialise remotely and what tools do you use? Do you plan virtual events?
How do you get into “work mode” working from home? Do you have a routine that gets you ready for the day?
Has the collaboration in your teams changed since working from home? How has it changed?
How are you keeping taking care of yourself during COVID, (mental health, learning, side projects)?

As someone who has worked remotely since 2008 I have a keen perspective on these questions. So I thought I would lay out some thoughts in this post in advance of the meetup.

Reflecting on Remote Work during COVID-19

Before I say more about working remotely during COVID-19 it is important for me to stress that because I have had the advantage of working remotely for many years, some of my recent experience is not that different from my experience during the previous 12 years.

However, perhaps that is one reason why I think I can offer a useful perspective about work during the pandemic.

Remote social connection

I’ve always felt that there’s something very valuable about mixing with work colleagues in a social environment, whether it’s at a pub or elsewhere. Obviously when all members of the work group are forced to work remotely from each other, the lack of such gatherings is brought into sharp focus.

Last week I realised that my own work group had been missing an element of social interaction. Before the COVID-19 restrictions came into force, I would visit the office in Melbourne every few months, enabling some important face-to-face interaction. It has now been nearly three months since my last visit and the next is unlikely to be any time soon. So, we have agreed to a monthly online gathering which has only two stipulations. Each member of the group will bring their beverage of choice and the online gathering will be strictly social. I’m hopeful that it will prove to be a fruitful bonding exercise. We shall see!

Remote work routines

My work group is currently all in the same time zone on the east coast of Australia. Several elements guide our daily work routine. First of all, we have a custom that when we start work for the day we announce that fact in our main Slack channel and set ourselves to active. This signal in Slack is a simple yet effective way of letting our colleagues know that we are working and available to collaborate.

Another key part of the “getting ready for the day” is our standup meeting, which we hold via a video call. Whilst we don’t conform to the traditional expectation of standing up, we definitely keep the meeting brief by sharing our main Trello screen and taking turns to let each other know where we are up to.

Our daily standup meeting is scheduled for 10am, which I consider to be a civilised time of day. Personally, I’m not an early starter. I tend to start work between 9am and 9:30am most days and usually work through until after 6pm. I find that our team’s 10am startup meeting is an importance cadence for our work pattern. It gives us a chance to get on the same page, understand what each other is aiming to achieve for the remainder of the day and then allows us to all get on with it.

For the remainder of the day, we communicate using whichever means is most effective. It may be via Slack, Trello, GitHub or, when the need arises, via a video call.

Remote collaboration

Has our team’s collaboration changed since we we all began working from home most of the time?

I find this question difficult to answer because I’m so used to working from home. However, I really don’t think it has much for us.

More generally, I will be interested to hear more about other people’s experiences. I know that some colleagues in the industry have found it difficult to adjust to working from home, especially those who live alone and are used to depending on social interaction in the workplace.

Taking care of yourself

How am I taking care of myself?

Well, I do try to maintain a discipline of doing my morning stretches and getting some exercise, even if it’s just walking the dog. And, in my case I’ve been fortunate to get in a few games of golf. Simple actions like getting outside and watering plants in my garden help my mental health as well.

As far as more work-related activities goes, I’ve been doing some work on the codebase that supports this site. I also provide occasional assistance to my startup partner on our side project, RemoteRetro, which, by the way, is an even more useful tool during these times.

And there’s always something work-related that I’m reading.

Remote Work in General

Advantages

I find it interesting to observe how people are adapting to remote work. To me it has many obvious advantages apart from helping prevent the spread of disease!

Here are a few that come easily to mind:

avoiding unnecessary travel time
allowing more time with family
allowing more time to do household chores
reducing my carbon-footprint

Acceptance

Acceptance of remote work by managers was a sticking point in many organisations prior to COVID-19. It will be interesting to see how much this attitude will have changed after the crisis has passed.

An obvious reason for a lack of acceptance in the past relates to trusting workers to actually spend the time that they’re paid to work by working. As software developers, it should be obvious how we can demonstrate that we are producing work of value.

Collectively, if we can use the tools at our disposal to demonstrate that we are being productive workers, hopefully greater acceptance will result.

Adopting Tailwind CSS

2020-04-13T23:28:16+10:00

It’s now more than seven years since I converted this site to use Twitter Bootstrap. At the time, I was pleased to be able to use Twitter Bootstrap to enable the site to be responsive to different devices.

However, time moves on. Almost two years ago I tweeted:

And this was the reply that interested me most:

More recently, at this year’s RubyConf AU opening party, my friend Josh Price was extolling the virtues of Tailwind CSS. So, when the recent four day holiday break presented itself, I took the plunge and converted this site.

The Process

There are plenty of good resources on the web about Tailwind CSS and supporting technologies so I don’t intend to provide a step by step guide here. However, I will reflect on the steps I ended up taking.

Remove Twitter Bootstrap

Naturally, having created a git branch on which to start experimenting with Tailwind CSS, the first step was to remove Twitter bootstrap. For me, that essentially entailed deleting the twitter-bootstrap-rails gem from my Gemfile as well as any references to it in my Rails application. As expected, that resulted in the pages on my site being displayed bereft of any styles.

Install Tailwind CSS

To install Tailwind CSS, I used this guide as a reference as well as the official advice.

So far so good. Now it was time to start making use of this “highly customizable, low-level CSS framework”.

Build up Tailwind CSS Styles

The next phase was one of experimentation. In some cases, such as for my Rails layouts, it involved applying Tailwind styles directly to <div> tags. This was the first time I started to realise that Tailwind adopts a mobile-first approach. For example, consider the following:

  <div class="block lg:hidden">
    <!-- other tags -->
  </div>

The significance of lg:hidden is that this tag will be hidden for devices of size lg and above where lg equates to max-width: 1024px. For more on Tailwind’s approach to responsive design, see the official documentation.

As I learnt more about Tailwind’s styles it became clearer to me that I needed to focus on the app/javascript/src/application.css file. In addition to incorporating Tailwind’s base, components and utilities styles, this is where I built up a list of styles to apply to various tags and classes. As a simple example, my first custom definition in this file is:

  p {
    @apply font-serif py-2 leading-snug;
  }

Translated, this means that for paragraphs, I apply Tailwind’s font-serif, py-2 and leading-snug styles. What do each of these mean? To find out, explore the documentation about font families, padding and line height. The documentation is very helpful.

Tailwind styles can also be applied to classes, as in the following example.

  .error {
    @apply text-red-700 pb-2;
  }

I’ll leave you to explore the documentation this time to figure out the meaning of the styles.

Use Custom Tailwind CSS Forms

Whilst I got most of the way towards styling my site using just Tailwind’s styles, I did find difficulties with forms. To solve this problem I used the Tailwind CSS Custom Forms plugin. I was then able to apply styles from that plugin as follows:

  form input {
    @apply form-input mt-1 block w-full;
  }

Complete transfer from Asset Pipeline to Webpacker

This site has been around for a while. I recall creating it in 2007. I can’t be exactly sure when because the git history only goes back to 26 April, 2009 when I migrated it from Subversion to Git.

Anyway, as a developer who leans towards the server-side, I’ve neglected some aspects of upgrading the site along the way. One of those has been moving from the Rails Asset Pipeline to Webpacker. That is no longer the case. As part of converting the site to use Tailwind CSS I realised that I needed to completely move my assets to Webpacker. The penny dropped when I understood the reason why the CodeRay styles that I use for code syntax highlighting were no longer working. After all, the following code snippet in my layout has a clue:

  <%= stylesheet_pack_tag "application" %>

The word “pack”, of course, indicates that the styles are managed by Webpacker.

Thankfully, the app/assets directory no longer exists in my application.

The Verdict

I now understand why Sebastian and Josh gave Tailwind CSS such enthusiastic endorsements.

Once I had experimented enough with applying the styles to tags and classes in a way that the styles could be reused, I found the experience addictive. And that’s saying something for a predominantly server-side programmer who cut his teeth on mainframes several decades ago.

On Communities in Crisis Mode

2020-04-01T13:01:29+11:00

Like many in Australia I’ve been at home for more than a week now.

For my work, that’s not so unusual. It has been well over a decade since I started working from home most of the time. So I haven’t had to adapt in the same way that many of my colleagues in the software development industry have.

The COVID-19 threat

Photo by Martin Sanchez on Unsplash

Obviously there is a broader community focus now that the spectre of COVID-19 looms ever larger.

For the last couple of weeks, as the risk of the coronavirus spreading in Australia has become more serious, I have been doing my best to stay at home. I’ve made no trips to my golf club in the last fortnight and those of you who know me well will know what a sacrifice that is!

In normal times I also look forward to Sunday morning trips to the local farmers’ markets. The Sunday morning before last turned out to be our last trip for the time being. We arrived relatively early to find the biggest crowd we’ve ever witnessed at these markets. Whilst they are classified as an essential source of food, we felt it was impossible to practice safe physical distancing. My wife and I decided it was, regrettably, our last visit for now.

Before

As I mentioned at the outset of this post, I’ve been used to working remotely for many years. In doing so I have gradually accumulated experience with using a variety of tools to become more effective as a remote worker.

The most relevant class of tools to this post is those that enable meetings via video. I’ll come back to those in a moment.

I think it’s also important to acknowledge that, until recently, my remote work was broken up by face to face social activity that I took for granted.

Whether it was sharing a round of golf with mates and catching up with others in the clubhouse afterwards, chatting with stall holders at the farmers’ markets or even enjoying my trips to the barber, there has been the simple pleasure of conversation in person to sustain me.

And to give me a break from the isolation of working alone in my home office.

New considerations

Now that’s gone. At least in my case I have my wife, who has recently started working from home full time, in the same house. I know others who live alone and don’t usually work from home are finding the adjustment especially challenging.

One thing I’m acutely aware of is the need to look after my mental health. My personal experience has taught me that I need to be careful not to let too much stress build up.

In my experience, antidotes to stress include getting outdoors, mixing with other people, playing sport and having a good laugh with others. There’s nothing quite like impulsively laughing or seeing the joyful laughter on someone else’s face as your joke lands.

COVID-19 obviously brings new challenges to staying sane.

Communities staying connected

So, how can communities help in these times of being distanced from each other?

Sometimes by necessity a community group that would normally meet face to face now has to meet via video. For example, only last night my golf club’s board of directors met via Zoom. To those in the tech community reading this for whom the mention of Zoom will raise a red flag on security grounds, please suspend your cries of protest! As we know, many people are adapting as they go, attempting to respond to this crisis as best they can as it unfolds. For some in our board, this was a first experience of a video meeting. Once we gathered all the participants and the meeting got into full swing, I sensed a reassuring feeling. A strong impression for me was the renewed connection between us, simply by virtue of being able to see each other as the discussion ensued.

Professional Communities

There are other contexts I would like to relate whilst writing about the theme of community in a crisis.

A professional community that I’ve been attracted to and involved in since 2018 is the Heart of Agile. Whilst there have been physical meetups all over the world, I was pleased to have the opportunity the other day to participate in the first fireside chat in an Australian time zone. I found the experience of being connected to more than 50 like-minded professionals via video to be quite uplifting.

Indeed, tomorrow morning it would seem that this community is facilitating a “drop-in” video hook-up. Maybe I’ll remember to drop in, we’ll see. Even if I don’t, I love the fact that someone has taken the initiative to make this opportunity available.

Since 2006 I have been privileged to be part of the Australian Ruby Community. I’ve enjoyed so many wonderful face to face experiences as part of this community, whether they have been meetups, Rails Camps, conferences or just catching up with friends that I have made as part of this community.

In recent days, I’ve drawn sustenance from friends who have taken the initiative to invite others to catch up over video. About a week ago I had, not to put too fine a point on it, a pretty shitty day. My Ruby friends Elle and Lachlan kindly invited me to drop into their place to chat online over video. Such kindness. The weekend before that my good friend Matt had facilitated a video chat amongst his professional friends. To hear the different ways that the economic fallout of the coronavirus had affected folks was humbling. And, last weekend, Pete put out a call over Twitter that he was interested in catching up. A video chat ensued, which allowed several of us in the tight-knit Australian Ruby community to share our challenges with respect to dealing with living in isolation.

To all these dear friends in the Ruby community, I express my heartfelt thanks.

An Approximation to Face to Face

Within and beyond the Ruby community I know that many meetups are adapting to hold their gatherings online. I had thought of attending the Sydney Elixir meetup last night but in the end was unable to.

Ultimately, we all crave connection to other humans, no matter how introverted we are. And, let’s face it, many programmers are.

During the coming weeks and months, the best we will be able to do in almost all circumstances, is to come together as communities with the aid of video meeting tools. Before you get too down about that, consider how it must have been 100 years ago as communities did their best to deal with the Spanish flu.

At least in 2020 we have tools like Zoom, Google Hangouts and Whereby.

Staying positive

In a way, the online connectivity of life in April 2020 is a double-edged sword.

On the one hand, technology brings the harsh realities of the horrific effects of COVID-19 into our lives in a way that is difficult to ignore. From an Australian perspective, what we see, hear and read of life in Italy, Spain, the UK and USA is sobering and disquieting, to say the least.

On the other, if we use the technology mindfully, staying connected within our communities via video tools can help. Whilst not perfect, it can provide us with at least a good approximation of what we, as humans, crave.

Reflecting on RubyConf AU 2020

2020-03-04T05:16:14+11:00

Life can get busy can’t it?

Among a myriad of things that have been on my list of things to do is write another blog post. Somewhat embarrassingly, as I write this, my most recent post was written over a year ago, when I reflected on the experience of presenting at RubyConf AU 2019.

Having recently attended RubyConf AU 2020, it’s only fair that I share my reflections about this year’s conference. If nothing else, it will provide some recent content on this site!

I think the following tweet from Josh Price echoes my feelings about RubyConf AU very well.

Whilst I know that Josh has moved on to focus on other technologies such as Elixir I agree with him that there’s something very special about the Ruby community. Here in Australia it is still going strong after emerging in about 2006. Eight conferences since 2013 and 26 Rails Camps since 2007 speak for the continued desire for the community to get together.

RubyConf AU 2020 Talks

So, what did I find especially poignant about this, the eighth edition of RubyConf AU? Whilst all the talks were worth paying attention to, let me select a few highlights.

Lemurs

I did use the word poignant purposefully just now with a reason. Brandon Weaver gave a story telling performance, Tales from the Ruby Grimoire, that certainly provoked echoes of Why’s Poignant Guide to Ruby, an online tome that has found a special place in the Ruby community’s folklore.

Brandon most definitely had me captivated as he facilitated the journey of several lemurs on their way to discovering more intricacies of the Ruby language. I’m sure his talk affected different people in different ways. For me, whilst I’m sure there was valuable content about programming in Ruby, I was blown away by Brandon’s artistry. The drawings in his slides were astounding. Then there was the storytelling itself!

Escaping

Talks about good code quality and how to pragmatically achieve it always hold my attention. Ernesto Tagwerker’s Escaping The Tar Pit was no exception.

Ernesto focussed on a topic dear to my heart: maintainability of software. To those who know me and know how much time I’ve spent maintaining codebases throughout my career, this will come as no surprise. Ernesto went beyond talking about code coverage using tools such as simplecov. When Ernesto honed in on code quality, I was interested to learn about RubyCritic, which I hadn’t previously been aware of. RubyCritic uses other tools such as flog and flay to highlight churn and complexity.

Ernesto didn’t, however, stop at code coverage and code quality. He went on to highlight a combination of the two, what he refers to as the “stink score”. He then referred to a tool, appropriately called Skunk, which measures this score.

Without giving away any more of the details of Ernesto’s talk, I thoroughly recommend it. That’s unless you’re happy to let your codebase descend into the tar pit, never to be recovered!

Documentation

Helpful documentation is something else that dear to my heart. I was delighted to see the way that Carmen Chung brought attention to this important topic with the title of her talk, How To Write Tech Documentation That Will Save Your Career.

Carmen took us through a journey of how incomplete communication resulted in a disastrous outcome, which could have been avoided by thoughtful documentation.

I think of my own current work environment and the multitude of opportunities for developers to thoughtfully leave clues for their colleagues about the reasons for their actions. It does require self-discipline and consideration for others. Carmen offered several useful tips for how to leave a trail of helpful documentation, using various tools to help others in the team.

However, as Carmen illustrated so well, there is also a considerable element of protecting yourself as well.

Experience

To close out the conference, I thought the organisers did very well to choose Xavier Shay’s talk on My Experience With Experience.

I loved one of Xavier’s opening statements, which was “learning from experience is hard.” To me that is such a thoughtful and honest thing to say. It begs the question that Xavier went on to explore: “how can we better learn from experience?”

Xavier initially introduced feedback loops and their role in learning. However, he quickly illustrated that this learning pattern does not apply to all situations. For example, it doesn’t help with improving one’s organisation of code.

When Xavier went on to talk about wicked learning environments, his talk grabbed my attention, which was quite a feat at this late stage of the conference. He referred to a paper by Hogarth et al entitled “The Two Settings of Kind and Wicked Learning Environments”.

Using the challenge of hiring staff as an example of a wicked learning environment, Xavier illustrated the inherent problem.

I won’t spoil the rest of Xavier’s talk. It certainly contained more nuggets of reflection and reference to others’ research. Suffice to say that I thoroughly recommend listening carefully to it.

This was a very thoughtful talk to end the conference.

Thanks to the organisers

As I said earlier, this was the eighth Australian Ruby Conference. As I know very well, they don’t happen without much effort.

I would like to pay my thanks to this year’s organisers, Rache, Ben and Caitlin. Undoubtedly, the support from Ruby Australia’s sponsors helps ensure that these conferences are financially viable. Equally, without the willingness of people to volunteer to help organise the conferences, they wouldn’t happen.

So, to Rache, Ben and Caitlin, once again, I express my heartfelt thanks for organising RubyConf AU 2020.

Reflecting on RubyConf AU 2019

2019-02-13T22:16:03+11:00

Surprise!

On 12th November last year I received an email via PaperCall with the following words which grabbed my attention:

Congratulations Keith Pitty!

We are really excited to let you know that your talk, “What were they thinking?”, has been selected for RubyConf AU 2019.

Can you please confirm that you will be able to bring yourself and your talk by visiting the link below?

I immediately felt a mixture of excitement and panic. Having submitted a proposal at the last minute I was now faced with the prospect of converting my abstract into a 20 minute talk that did it justice and provided value to the audience.

I accepted the challenge and earlier this month presented at RubyConf AU in Melbourne!

My Talk

The genesis of my talk was many years of thinking about experiences I have had with codebases. Legacy code that hasn’t been loved can result in painful experiences for future developers, frustration for users not to mention expensive consequences for owners.

So that’s the background. You can watch the video and see the slides for yourself. To give you a bit more of an idea of the content, I’ll give a quick overview below.

Thanks to John Carney for this photo of me presenting.

Disciplined Development

Software is liable to decay over time unless it is nurtured. Such nurturing should include such things as refactoring to improve internal design, which implies automated testing, sufficient up-front design to increase the likelihood of a successful outcome, healthy peer review, a well documented git history and load testing.

All of this requires discipline. Sometimes it also requires negotiation with stakeholders.

Planned Maintenance

An aspect that can involve both discipline and negotiation with stakeholders is planning and carrying out maintenance such as installing security patches and keeping software on which your applications depend up to date.

Whilst attention to the detail of planned maintenance is something that many developers can do well, negotiating with business owners to give it sufficient priority is a different challenge altogether.

Philosophy

Before delving into the challenges to communicate better, I touched on a couple of more philosophical topics which I considered relevant to the topic. Firstly I referred to what is sometimes described as “continuous flow”. I then suggested that it was time to reflect on how a mature consideration of the Agile approach could better serve us.

Persuasion

In my experience it can be difficult to persuade some business owners of the vital importance of the sort of activities that are essential to keep legacy codebase in a healthy state so that it survives in a form that enables it to support evolving needs.

The challenge to practice becoming more persuasive comprised a large part of the second half of my talk.

Feedback

Once I had given my talk I was delighted at the positive feedback I received in person, whether it was from other speakers, former colleagues or new Ruby acquaintances. By the way, there were many inspiring talks at the conference so if you weren’t there I encourage you to watch them.

When I looked at Twitter I was humbled to see lovely feedback such as the following from Mel.

I’m keen to hear further reactions, especially from those who weren’t able to be in Melbourne for the conference. We were so lucky that the organisers engaged Next Day Video who in fact made the videos of the talks available on the same day!

So, if you’d like to get in touch and give me your take on my talk, please feel free to do so either via this site or Twitter.

Thanks

Finally, a big thank you to all who made my experience at RubyConf AU 2019 so rewarding: those who selected the talk, my family for listening to me practice, the organisers, the lovely MCs, the audience and especially those who were kind and thoughtful enough to discuss my talk with me afterwards.

Remembering Jerry Weinberg

2018-08-12T22:20:46+10:00

I’ve been thinking about Jerry Weinberg’s writing over the last few days, since his passing moved many including myself to words in his honour.

His words inspired me.

I know that I’ve dipped into the pages of The Secrets of Consulting many times over the years. I should probably, in the near future, take time to refresh my memory of the excellent advice that I know that tome contains. And I know there are many other books of Jerry’s that are worth reading or re-reading.

However, of all Jerry’s writing, there is one book that stands out to me. I was moved to write about it back in 2007 in a now defunct blog. Fortunately I have an extract of the text.

I introduced my post with a a reference to a picture of a beautiful stone wall in my back yard. Whilst I’ve lost the original photo, here is a fresh one of the same wall:

And here’s what I wrote:

What a beautiful stone wall! My family is now lucky enough to have this wall in our back yard. The bloke who built it is obviously a master of his craft.

What does our wall have to do with writing? The answer is to be found in Weinberg on Writing, a thought-provoking book about how to write using the metaphor of building a fieldstone wall.

Jerry Weinberg addresses the problem of writer’s block by showing how metaphorical stones can be continually collected. Each stone may or may not end up as part of a published work. The process of collecting stones typically contributes to ongoing work on a number of potential finished books, articles, reports or even blog entries. The trick is to always be ready to write. Carry a pen and notebook everywhere so that ideas can be readily captured. Later on the stones can be organised, perhaps eventually being crafted together in a finished wall to be admired. Or perhaps not. Stones may be thrown away during the editing process.

I think the Fieldstone Method employs a useful metaphor that keeps the writer productive. Of the many lessons in this book worth heeding my favourite is Jerry’s first: “Never attempt to write something you don’t care about”. After all, a fine stone wall is built by a master craftsman with passion. Writing should be similar.

Although I never met Jerry, that’s the lasting impression I have of him. Passion poured from the pages he wrote.

The software development community is very fortunate that Jerry has left such a wonderful written legacy. If you have a thirst for learning from a pioneer of a people-oriented approach to programming about topics ranging from consulting, becoming a technical leader, systems thinking, testing, exploring requirements and, of course, writing, amongst many others, I thoroughly recommend reading his books.

Jerry may be gone but his words will live on.

On Mentoring and Being Mentored

2018-03-30T23:07:03+11:00

Background

Why would I choose to write about mentoring?

I guess it’s a topic that I’ve pondered over the years, ever since my first job out of university. During the couple of years I worked at TNT I didn’t benefit from any formal mentoring. However, when I think of who had a big impact on my learning on the job, there were certainly a couple of people who immediately come to mind.

But it was when I arrived at IBM that I was struck by the fact that everyone in the team was allocated an adviser. So I knew that, if I ever had any questions about anything, I could approach Rod, my adviser. I knew he had a wealth of experience and found his help invaluable. What impressed me even more was the fact that the company considered mentoring important enough to implement such a scheme.

That was back in 1986. Fast forward to 2018 and I’m in a very different situation, keenly aware of the need for young programmers with whom I work to have good mentoring.

So, several weeks ago, at RubyConf AU, when Alaina Kafkes challenged those in the audience of her talk about Tackling Technical Writing to publicly commit to writing about a particular topic, my response was:

And given that Sean was generous enough to say that he’d read what I had to say on this topic, it’s only fair that I put words to the screen and share my thoughts.

Mentoring Others

Meaning

Before I dive into my thoughts about mentoring others, I think it pays to pause and consider the meaning of the word mentor. The dictionary on my Mac defines a mentor as:

An experienced and trusted adviser.

Now that we have that definition out of the way, let’s consider what it takes, in my experience, to be a good experienced and trusted adviser.

Patience

One thing that I consider to be vital when mentoring is to be aware of the right time to offer advice. As a parent I’ve come to learn that one has to be patient and wait for the right moment. Or, to borrow from another context, I love the quote from Jack Gibson, the Rugby League coach, who said:

“A good coach thinks twice and says nothing.”

In other words, try to cultivate a sense of recognising moments when your colleague is ready for advice. It’s important to allow them the time and space to try to figure things out for themselves. You’ll usually know when they’re ready for your advice. They’ll ask you a question!

On the other hand, there will be times when your colleague could use some advice but doesn’t ask for it. So make it clear that he or she is welcome to ask questions about anything.

And then wait.

Provide a framework

It’s one thing to encourage your mentee to ask questions. However, to provide them with the basis to ask good questions that will help them learn, a framework will help.

What do I mean by a framework?

To begin with, something that provides structured learning. To be fair to your colleague, they’ll need training to help them be most effective at their work. Appropriate training will help the developer feel that they have ascended to a new level and give them confidence. That confidence should translate into a greater preparedness to attempt new tasks and, importantly, spark questions that will further improve understanding.

Also, it’s likely that different members of the team will have different strengths. Part of my envisioned framework is a skills matrix. For each skill there will be specialist mentors as well as a set of training resources.

In the early stages of implementing a mentoring program for a team, there may be a few gaps and imbalances in this matrix. For example, a skill that is important to the team may be Ruby Performance Optimisation. However, there may be nobody in the team that has sufficient strength in that skill to mentor others in the team. A next step to start filling that gap may be to identify some training resources, allocate one developer to complete that training and then become the mentor for that skill.

Continuing in this way, the skills matrix should start to take better shape. The aim should be to manage its evolution so that there is an even spread of mentors across the skills that are important to the team.

Everyone is different

Naturally we all differ. We gravitate towards different skills. We think differently. We have different needs.

So, in my perfect mentoring world, the needs of every individual should be provided for by a mentoring program that is fine-tuned and continuously adapted for that person. In practice this may not always be possible to the ideal degree. However, I think it is worth striving for.

Consider the other’s viewpoint

Perhaps this point is obvious.

However, I think it’s worth stating explicitly. Whether it’s during the process of creating and maintaining a mentoring framework, or in the act of mentoring, it pays to put oneself in the shoes of the other.

What are they keen to learn? What do they think they need to learn in order to do their job better? What do you think they need to learn in order to do their job better?

It pays to explore these questions in an open manner.

Pairing

Working as a pair, where one developer is a mentor and the other is more focussed on learning, can be an effective way of enabling a junior developer to grow. Whilst in general a more typical pair programming approach would involve two developers who are on a more or less even footing, switching the driver and navigator roles, a mentor/mentee pair offers an effective learning experience.

Having said that, there is a caveat. When there is a marked difference in skill levels, pair programming can be intensive and tiring, especially for the mentor. So it is important to be aware of this and provide sufficient breaks between pairing sessions. Ideally, as Ryan Bigg emphasised in his talk about hiring juniors at the recent RubyConf AU, a task that can be completed within two to three days is a good choice for this style of pairing.

One-on-one

As I alluded to previously, it’s important to consider the point of view of the person you are teaching. It’s not going to be surprising for them to feel self-conscious, even overwhelmed at times. So, as a caring mentor, ensure that there will be regular opportunities to catch up with your colleague in a one-on-one context.

I’m reminded about a coaching context again. When you’re coaching a team or a group, it pays to offer praise in public. It makes the recipient feel good. A little bit of an ego boost goes a long way.

On the other hand, if there’s a need for some constructive criticism, this is obviously best given in private. Nobody likes to be given negative feedback in front of their peers.

Being Mentored

Identifying mentors

When you’re a younger worker, learning your craft, it shouldn’t be difficult to identify trusted advisers. However, as one grows older, mentors aren’t as easy to identify. I know that from experience.

And I have to admit that in recent years I have struggled to find a single person who I can look to for advice as my professional advisor. When I consider my experience over the last decade or so, it leads me to reflect on the various needs I have for advice.

Perhaps, in my case, as an older, experienced IT professional working within a small group of developers, I need to be more flexible in the way I seek advice.

Relevant experience

My need for advice may stem from different sources.

In a more general, career sense, given that I’m closer to 60 years of age than 50, it’s likely that I need to look broadly to find someone who can give me appropriate career advice. Or, perhaps, I need to consider my own counsel. However, having said that, I think that’s probably a lazy response. Even though it will take more effort, I think it’s worth my while to keep searching for someone who I feel I can trust to give me good advice about how to approach the closing decade of my career as a software developer. Such an advisor will most likely outside my usual circle of professional colleagues.

Then again, my need for advice in a professional context may result from other sources. Perhaps I will need specific technical advice?

Younger mentors?

It shouldn’t be surprising in the context of professional software development as a senior practitioner to encounter situations where younger colleagues have greater expertise in specific disciplines and technologies. One only has to think of the latest JavaScript framework to develop a keen appreciation!

I’m certainly not too proud to seek advice from younger developers about technologies such as React and Webpack, for example.

So I guess, in essence, I think I should be prepared to seek and accept advice from different mentors for different topics.

Getting specific advice

At any stage in one’s career I think it makes sense to be flexible about seeking specific advice. Obviously some people are going to have greater expertise in particular topics than others.

In my own case, I think it definitely makes sense to think of seeking advice in specific terms. Who has the best advice to offer about specific skills?

So, when I’m looking to be mentored, it probably makes sense to consider the same matrix that I proposed earlier.

Wrapping up

One of the things I love about working as a software developer is the opportunity for learning and teaching.

It’s pretty rare to go through a career in software development without working as part of a development team. Every member of a team needs mentoring and most will be in a position to also help others in their team. Even if you spend much of your career as a freelance developer you will benefit from and be in a position to provide mentoring.

I hope this post has stimulated your thinking in some way about mentoring.

After all, when you think about it, it’s a two-way street. There are obviously going to be times when you need advice. So, it seems only fair that you be prepared to offer advice as well!

Moving on to Birdsnest

2017-12-08T18:47:23+11:00

For the cast of thousands who hang off every word that I write on this site I am delighted to announce that I will be commencing a new role in the new year!

In January I will be starting work as a Senior Software Developer with Birdsnest, an online retailing company based in Cooma, NSW.

Whilst I will be based at my home office on the NSW Central Coast, I will be making regular visits to Cooma to work with staff on-site, especially the software development team.

Birdsnest is an inspiring company that offers a unique online shopping experience.

I look forward to working with the development team to help them build upon their successes to date.

Available in the New Year

2017-11-20T21:34:51+11:00

The new year promises to bring new challenges.

Yes, having contributed to The Conversation’s development team as a contractor since June 2015, I will be moving on in late January, or earlier if I am able to provide fair notice.

I’ve very much enjoyed the opportunity to work with The Conversation over the last two and a half years and will have fond memories of collaborating with development colleagues as well as editors of the various editions around the globe.

What’s next?

I’m open to both consulting and permanent roles. If you’re looking for a seasoned, passionate software developer who has a track record for helping people by solving problems, please get in touch.

On Non-Determinism

2017-10-21T11:03:01+11:00

It’s something that irks me.

I’ve seen it time and time again. Martin Fowler was moved to write about it and speak about it in 2011. I’ve stressed it’s importance many times since. Again recently I was moved to share it:

Resistance

My observation has been that developers are resistant to accepting the challenge of battling the scourge of intermittently failing tests.

What is the reason for this resistance? This is something that has intrigued me for years. And I’d like to delve into it in a little more depth.

Time and Effort

I suspect that part of the human impulse to resist addressing non-deterministic tests is the intuition that to accept such a challenge might lead to much time and effort expended for little result. If that is the case, believe me, I understand. Fixing this sort of problem is not for those faint of heart!

Having experienced the struggle of identifying what causes an intermittent failure, I know it isn’t easy to unearth the root cause.

Quarantining

In my experience there is a palpable resistance to Martin Fowler’s suggested approach of quarantining non-deterministic tests. On one level, this bewilders me. As Martin illustrates, if a test cannot be relied upon to pass or fail, it is worse than useless. It is infecting the whole test suite. So, the sane approach is to, at least temporarily, remove it from the test suite.

Whenever I have suggested this, I have been met with resistence. Developers claim that the test is useful, that it provides protection as part of the regression suite against bugs being introduced. I’m still searching for a way of countering this argument, which is clearly fallacious. As Martin quite rightly asserts, if a test cannot be relied upon to pass or fail against the same codebase, it is worse than useless and must be immediately quarantined!

Sure, there is extra effort involved in configuring the quarantining process. The use of RSpec tags is handy for this. Then there is the perceived risk of the team forgetting to fix the quarantined test. Again, it requires some effort to set up, but it is certainly possible to automate warnings to the team about tests that have been quarantined for too long as well as build pipelines that contain too many quarantined tests.

Removal

Of course, another possible response to a troublesome non-deterministic test is to simply remove it from the suite.

This may sound radical, but let’s consider the situation from a cost/benefit perspective. If a test cannot be guaranteed to reliably pass or fail then it is clearly not providing much benefit. If it takes considerable effort to debug and still cannot be guaranteed to reliably pass or fail, what should the developers make of it? It has clearly already absorbed considerable cost. This leaves the question of potential benefit.

A related question is: how crucial is this test as part of the suite? Is it a vital part of the test suite? If the answer to this question is “yes” then it is appropriate to continue trying to solve the non-deterministic behaviour. However, if the answer is “no”, there seems little value in keeping the test within the suite.

Laziness

People are naturally lazy. Why do something that requires effort unless you really have to or there is a clear benefit that will accrue to you?

If a developer is working on a pull request, pushes a commit and the resultant build on the CI server fails with an error that is obviously unrelated to their pull request, what’s the easiest thing to do? Click the button to rebuild the test, of course! The temptation to take this action, even if the developer in question has the appreciation that this may not be a helpful response in the even slightly longer term for his or her colleagues, can be compelling.

I’m not sure of the best way of countering this. Appealing to the greater good?

Priority

Usually when a developer notices an intermittently failing test their focus is elsewhere. They may be working on a feature and notice that the build fails due to a non-deterministic test that is unrelated to their feature. Or they may be watching the master build in preparation for a deployment. Understandably the priority in these scenarios is to enable the feature to be merged or the deployment to go ahead.

The key here is to at least take some action to fix the non-determinism, even if it is to schedule some work to rectify the situation later. Unfortunately, in my experience, the tendency is often to ignore the intermittently failing test.

Causes

As Martin Fowler points out, there are many causes of non-deterministic tests. Among them are:

lack of isolation
asynchronous behaviour
remote services
time
resource leaks

Each of these deserves an article on their own. In Rails applications, the type of intermittent failure I’ve seen most is due to asynchronous JavaScript. Indeed, it is interesting to note that An Empirical Analysis of Flaky Tests found that 45% of flaky tests were due to the test execution making an asynchronous call and not properly waiting for the result of the call to become available before using it.

Much has been written elsewhere about dealing with non-deterministic tests that use RSpec and Capybara. For example:

Maria Verba gave some tips and best practices for identifying and fixing bad tests
Nebojša Stričević gave some guidance about how to deal with and eliminate flaky tests
Gabe Berke-Williams wrote about giving Capybara a helping hand by introducing a wait_for_ajax helper

Added to this, Keith Pitt has detailed 5 ways we’ve improved flakey test debugging, which focuses more on how to capture the database state when a test fails intermittently.

They are all worth reading. However, what I’m pondering in this article is more to do with motivation.

A Way Forward

How can we best encourage developers to tackle non-deterministic tests?

Expecting the person who first notices the failing test to fix it is probably not a good approach. After all, that person is likely to be feeling frustrated or even angry that an unrelated test failure is holding up their progress.

A colleague of mine recently suggested assigning the task of fixing a non-deterministic test to the last person who changed that test. It’s a helpful suggestion that at least circumvents the frustration that I wrote about earlier. It also assumes that the team member assigned to fix the flaky test is willing and capable.

Of course, keeping a CI build healthy is a shared responsibility. The build is more likely to be healthy if all members of the team contribute to meeting the challenge posed by non-determinism.

A Parting Thought

In my case, one thing I need to be mindful of is to be careful not to let the frustration that I sometimes feel become counter-productive. As Kent Beck implied a while back, as well as working in small increments, it is important to be both kind and honest.

If I follow that advice hopefully I will respond to discovering non-deterministic tests by gradually finding ways to help the team to handle the challenge of fixing them more successfully.

Achieving Flow in a Development Team

2017-03-16T23:12:03+11:00

One day last June I was moved to share an opinion on Twitter.

And as the following exchange shows, at least one reader, my former colleague SengMing Tan, expressed a desire to know more.

As I foreshadowed, it has taken me a while to get around to elaborating.

However, the time has come. After nearly a year has elapsed I am fulfilling my promise.

Here is a description of how the team I’ve been working in at The Conversation uses Kanban, Trello, GitHub, Buildkite and Babushka to develop, review and ship software in a way that encourages flow.

Tools and Techniques

Kanban

Whilst there are several tools that we use which combine to help our team feel that we are constantly making progress towards shipping software, it is the Kanban system which underpins them.

As I understand it, the team started out with a low-fi approach by using a physical card Kanban wall. But by the time I joined, they had moved that wall to Trello. Which was just as well, because I was the first remote member of the development team.

Nevertheless, I think it is the Kanban style of only allowing a specified maximum number of cards in each “swim lane”, that is crucial to the overall feeling of progress that our team has.

Trello

As anyone who has used Trello knows, the general style is to represent progress by aiming to move cards from left to right across the columns. Whilst there are other columns on our development board, the following image depicts those that are essential to the way Trello supports our Kanban style of development.

I’ve blurred out the details of the cards but the key things to notice are the column headings. Notice that we have upper limits set for how many cards should be Queued, In Progress or under Review. This helps us each individually focus on completing a piece of work. As a team, it draws attention to ensuring that work is reviewed in a timely manner. If more than six cards are in the Review column, we consider that to be a broken state. It is a prompt to the team to give more focus to reviewing pull requests until we can merge enough of them and move the corresponding Trello cards to the Ready column.

There are other columns on our development board such as Confirmed to the left and Complete to the right of those shown in the screenshot. And we have other boards. However, in the context of how we use Trello to help the team achieve flow, the four columns shown demonstrate what is at the heart of how we use Trello.

GitHub

One of the things I like about the paid version of Trello is the various Power-Ups. I find the GitHub Power-Up particularly useful. As I have written elsewhere, when I’m working towards a solution I prefer to share code via a pull request as early as possible. Fortunately our team has a strong culture of providing respectful feedback via pull requests.

There are times when I feel the need to gently prod my teammates to provide feedback on my pull requests. However, once the conversation within the context of a GitHub PR starts, it is usually very helpful. I like the way the tone of our comments tends to be questioning and curious rather than judgemental.

Once a Trello card, with a linked PR, is designated as available for review, it is important for the team to give it timely attention. Occasionally attention is diverted elsewhere. For this reason our team programmed our Slackbot to inform us if a card has been in the Review column for too long. To me this is a helpful prompt to keep contributing to the effort that will result in shipping software. Speaking of Slack, its integration with GitHub is an obvious boon. Being able to see via our main #dev Slack channel when a PR is created or merged certainly helps teamwork.

Being able to easily trace code changes in a PR that result from a Trello card is wonderful for maintaining flow. Did I mention how much I love the Trello GitHub Power-Up?

Buildkite

The ways in which Buildkite can assist teams achieve flow is worthy of a post in itself. For the purposes of this discussion, I’ll confine myself to the way Buildkite is integrated into our team workflow.

We use Buildkite to automate our continuous integration builds. Unsurprisingly it is integrated with GitHub so that it’s easy to see whether or not the build has passed for the latest commit on a PR. Then there is the Slack integration, which I find useful as another prompt about the success or failure of builds. There are times when the first place I’ll notice a build failure is via our #buildkite Slack channel.

Obviously part of achieving flow is ensuring that the build for a PR is successful before that PR is merged. And, of course, the build for the master branch must be before we can deploy.

Babushka

Whilst we have not yet reached the point where we continuously deploy our software, we do typically deploy applications several times each day. The tool that helps us software is Babushka, courtesy of an alumnus of The Conversation, Ben Hoskings.

Babushka may not be as well known as other tools which support deployment but it has served our team well so far. Once a master build is for an application and we are ready to , it is a simple matter of entering babushka ‘SHIP IT’ at the command line and the defined dependencies will enable babushka to deploy our software.

Summing Up

It’s all about flow. As emphasised by psychologist Mihály Csíkszentmihályi, in a personal context flow is “the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity.”

Translating this concept into a software team, we can see that it is important to remove as many barriers as we can to the team being fully immersed in shipping quality software. The Kanban approach supported by various integrated tools can certainly help in this regard.

And, in my experience, it can be fun too!