Back To The Forge

I do a decent amount of project management.

It's mostly facilitation work: getting people together, clearly articulating goals and success criteria, ensuring a shared consensus, breaking things down into meaningful chunks, etc, etc.

So, recently, when I got some innovation time, I naturally fell into doing a project of my own. Specifically, I wanted to establish a brand-new social construct that used video games to help people bond remotely.

I failed.

Now, failure isn't bad, especially when you learn lessons along the way. I'm choosing to mentally repositioning it as a step in the general direction of victory. Mostly.

The experience did help me to realise that maybe I should use innovation time differently. Instead of just doing what I do on a day to day basis, maybe I should do something different.

You know, like actually build a piece of software.

The Best Weapon Is One You Never Fire

The best part about the innovation activities and events at Atlassian is that there is almost always a central register of some sort, where you can see what sort of ideas people want to delve into.

Unsurprisingly, it's Jira.

In my search for something I could contribute to, not necessarily own, that was technical in nature, I didn't really have to look all that far. One of the people from my own team had a great idea to build something to help us manage our runbooks.

For anyone unfamiliar with the concept, a runbook is essentially a recipe for accomplishing some sort of technical task. You know, a list of ingredients and instructions in order to provoke a certain outcome.

This is Site Reliability Engineering though, so for us, a runbook is often the first step in creating some sort of automated solution. It helps us to understand what exactly needs to happen and in what order, and allows us to test what essentially amounts to an algorithm.

Some of our runbooks live a long time before being automated though, usually because the investment in said automation is hard to justify (a relatively infrequently performed task) or because the domain is complicated.

As a result, we have a bunch of runbooks in various states and we often find ourselves with a fierce need to wrangle them, ensuring that they are complete, accurate and up to date.

And thus, the innovation idea, a Runbook Manager.

Actually, It's The Weapon You Fire Once

Long story short, because our runbooks are primarily stored in Confluence, we decided to implement a Forge app that did all of the things. Specifically, it would have a macro that you could add to a runbook page to augment it and some background tasks to facilitate a review workflow.

Forge apps are written in JavaScript and are a Function-as-a-Service (FaaS) kind of thing. You put together a small chunk of code that has various entry points, which in turn runs within a sandbox that has access to a wide range of things (i.e. Confluence APIs, Jira APIs, storage, etc).

It's actually a pretty awesome setup. You know, except for the fact that it requires you to write JavaScript.

From my point of view, this was the first time I would be doing any meaningful development since I mucked about in HackerRank, and that was an entirely different and much easier development environment.

I assumed I would have to do a bunch of yak shaving before I could contribute meaningfully.

Turns out that was something of a fallacy, as I can contribute meaningfully via the magic of pairing, even when the task at hand is software development.

Of course, it helped that the person I was working with was an actual honest to god developer and was incredibly competent. I mean, he didn't know how to write good JavaScript either, but we did manage to make some progress all the same.

In the downtime between pairing sessions I did manage to set up my development environment, which was a nice little victory. I even managed to knock up a PR successfully on the repository we were working on.

Granted, it was a documentation change, not actual code, but I'm counting it.

Dummy Is On Fire Safety

At the end of the day, we didn't quite get all of the functionality done that we wanted, but such is the nature of innovation time.

We got caught up on some of the unknown unknowns that are typical in software development, especially when using a brand-new framework. For example:

• We didn't really understand the development/deployment model at first. It turns out the manifest for the app doesn't get automatically deployed when you change it with forge tunnel active, so our brand-new hook for testing the scheduled task for the reminder was wired up to nothing and kept failing with an arcane error
• We weren't even sure if we were using Forge correctly. Basically, we wanted to build up a set of pages tagged as runbooks by "enrolling" them, but the mechanism we chose for enrolment was the presence of the summary macro and there is no easy way to iterate through pages that contain your macro in a Forge app. We figured out a way around it (by using storage to store a page-id whenever the macro was added to a page), but the solution felt kind of dirty
• Speaking of dirty, JavaScript. Neither of us knew how to write good JavaScript, so what we created in the end was...somewhat horrifying
• The documentation was somewhat lacking, which made it difficult to get started. Don't get me wrong, there was definitely documentation, but it didn't really explain things in a way that we could easily pick up

But running into and surmounting those sorts of challenges is all part of the charm of software development and I remember it well.

Just Stick To The Cards Man

I thoroughly enjoyed my time doing software development again, even if it was somewhat indirectly through another person.

It was good to talk about models and patterns and just code in general, and to make a thing that delivered some value. Not a huge amount of value granted, but still more than zero.

It reminded me that the feedback loop of software development is so very short in comparison to management and project facilitation. You can have an idea and implement that idea in a matter of minutes or hours.

These days, whenever I have an idea, it takes days, weeks or months before I see the fruits of my labour. If I even see fruits at all.

Positive reinforcement is a hell of a drug and I want more.