20 Dec 2019 Five things I learnt at YOW! Conference 2019
So I just attended the 2019 YOW! Conference in Melbourne. There were wacky booths, certified delish food (see picture above), and a whole heap of swag. There was also a star-studded lineup of speakers presenting amazing content that was both insightful and challenging.
In this post, I’m going to share with you the top 5 things I came away from the YOW! conference with. While most of these things were inspired by something a presenter said, they are also strongly informed by my own experiences. It might have even been the case that what inspired me wasn’t the main point of the presentation!
#1: Don’t be afraid to deploy
The first keynote speaker to kick the conference off was Gene Kim with his talk “The Unicorn Project”, which is also the title of his much anticipated follow-up book to “The Phoenix Project“. Somewhere in the talk, Gene mentioned this evaluative question we developers should ask ourselves:
“On a scale of 1-7, how afraid am I of doing a deployment?”
He built further on this idea by introducing to us the concept of an Andon cord. For those like me who are unfamiliar with this, its a pull-cord (or maybe a button nowadays) which every person on Toyota’s manufacturing floor has access to. Along the whole assembly line, any person, regardless of rank, who spots any sort of defect, or even a suspicion of a defect, should pull the cord. That entirely stops the production line. People immediately come to inspect the defect, fix it, and ensure as best as they can that the problem is fixed at its source so that the Andon cord will not be pulled again for the same reason. Only then will the assembly line restart.
These 2 considerations made me reflect on my day job. I’ll share a little example that happened last week. My team has two kinds of services we maintain/provide, micro-services in the cloud and legacy services sitting in on-prem hardware. I admit that I’m not always a good team player, so when I hear about a JIRA ticket relating to one of our legacy on-prem services, I try quite hard to not pick it up because I know that if I work on it, I’m going to be involved in the deployment of it.
Just last week, one of my teammates had the painful privilege of deploying out some changes on a legacy service. The development work was done months ago, but we hadn’t deployed the changes to production. It took him the entire week just to get it deployed. The first 3 days were spent “fixing” the CD pipeline (I use “CD” very loosely here) and making sure our integrated test environment would be able to run our automated tests. The remaining 2 days involved all the paperwork, and finally the actual deployment itself. So come this Monday morning, there was an announcement made to the entire wider team to congratulate this colleague of mine on successfully completing this amazing feat of deploying one of our services! Hooray! We deployed our service!
So, returning to Gene’s question, on a scale of 1-7, how afraid am I of doing a deployment? 7. Maybe even 8 but then I’d be breaking the rules, so let’s keep it at 7.
I then started thinking about the Andon cord. Would I, or my team, have the guts to implement something like this? Or would we steer away from it simply because we know how often the cord would be pulled, and how it would result in no service ever being deployed?
Take a guess at how many times the Andon cord was pulled in a typical day at Toyota’s manufacturing plant. Go on, take a guess before reading any further.
3500. Yes, 3500 times a day! Do they even do any work at that plant? Well, maybe not much at first, but slowly, over time, they’ve become more productive than ever before. It shows how committed they are to improving, never afraid of failing. I’m going to try to emulate this courage a bit more when dealing with our software production line.
#2: My retros can be wayyyyy better
One of the talks delivered by Aino Corry was titled “Retrospective Antipatterns”. I’ll admit I went to this talk because I haven’t been really happy with my fortnightly retros lately, and figured maybe she could teach me a thing or two to change things up.
She presented 6 anti-patterns but I’ll only address 2 of them.
The first anti-pattern is called Prime Directive Ignorance. Basically it’s about not knowing the Agile Prime Directive, which is this:
“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.”
–Norm Kerth, Project Retrospectives: A Handbook for Team Review
I was a bit blown away by how succinctly put that statement was. I also realised how often I have violated that directive, leading to perhaps some bitterness and general unhelpfulness in growing as a team.
Aino suggested that we bring the directive into each retro, be it written up on the whiteboard, verbally said, included in an email, whatever. The Prime Directive is key to a productive retrospective, and being ignorant of it is going to undermine a lot of the point of having the retros. This anti-pattern might be less of a thing the rest of my team needs to address, but I think it’s an important thing for me to remember next time.
The second anti-pattern is called In The Soup. Here’s a diagram to help explain it:
Essentially, after collecting everyone’s thoughts on post-it notes, and before talking about them, we should run through the process of placing all those thoughts into the 3 rings.
I’ve noticed many times that my retros spend a lot of time dwelling on “the soup” and we walk out without many concrete actions. Instead, Aino suggests that together we first try to move our post-it notes inwards. How do we transform soupy post-it notes into something more concrete? Something that we can have control over? I hope to implement this at our next retro and see if our retros end up feeling less hopeless and directionless.
#3: Respect history
Now this is a lesson I really didn’t expect to learn. Cat Swetel gave a talk hilariously titled “193 easy steps to devopsing your monolith“ where she shared her journey of “devops-ing” a super-legacy system which I’d never heard of before. It was on some ancient codebase that now runs on some ancient emulator. I wish I could remember the details and tell you about them but it was so obscure that I simply can’t remember it. However, what I do remember is that, somewhere in there, she mentioned this:
“only successful code becomes legacy code”
I currently consult at one of the big 4 banks of Australia, and boy-oh-boy let me tell you about legacy! If you search Google Images for “mainframe ui”, you’ll see screens with black backgrounds and bright mostly-green blocky texts. Yeah, that’s what is in place at most banks in the world. The first time someone from the mainframe team sent me a screenshot of the data I was looking for, I both laughed and cringed.
I have the good fortune to be working with nice, clean, modern and usable GUIs. IntelliJ basically writes much of my code for me. In contrast, the mainframe team were stuck on monochrome console UIs from the 50’s. My first question was: how can I take this seriously?
But as Cat said: “respect history”. For, upon reflection, I realised: who am I to be denigrating the backbone of all the bank’s processes? These systems have worked for decades, and still work! It’s a testament to their success that they’re still here. The system that I was mocking (or something just like it) probably ensures that my pay ends up in my bank account every fortnight. That’s one thing that IntelliJ can’t do.
#4: My passwords are not secure
The last speaker and keynote of the conference was “Rise of the Breaches” by Troy Hunt. This was, for me, the highlight of the conference. It was a hilariously engaging, informative, challenging talk on the state of cyber security in today’s world. Troy’s talk spanned data breaches, insecure APIs, and the elusive, mysterious idea of “hacking”. But for me, the biggest lesson concerned crappy passwords.
Somewhere within his talk, Troy went through a little exercise with us all, and I’d like you to try it yourself now.
Start by imagining your favourite go-to password. It probably started off as your landline phone number from back in the day, or maybe it’s the name of your first pet hamster Ron (who disappeared one day after you forgot to close his cage). Somewhere along the line, some random website told you that your password was not secure enough. What? How dare you tell me that ronthehamster is not a secure password! Fine! You want a capital letter, I’ll give you a capital letter. Have a guess now at what the new password will be? Ronthehamster? OMG! You mind reader!
Wait what? Ronthehamster is still not a secure password? You want me to put a number in there? Fine! Have a guess now at what the new password will be? Ronthehamster1? Or maybe Ronthehamster4 because 4 is my favourite number.
You’re kidding me! It’s still not ok? You want a what? A special character? I’ll give you something special alright. Have a guess now at what the new password will be? Ronthehamster4!.
Whatever, at least it’s secure now. The website stopped complaining about my password. Fast-forward 3 months and the system is yelling at me that I need to update my password! Ridiculous! Fine, you want a new password? I’ll come up with a brand new password. Have a guess now at what the new password will be? Ronthehamster5!.
Was I correct? Did anyone go through this exercise and think “oh my goodness I do exactly the same thing? That’s how I felt. Troy explained that we humans are lazy by nature. We will take the path of least resistance to overcoming the obstacle in front of us. Websites and systems that set up “password security features” like this lead us to feel that our passwords are an obstacle and annoyance, rather than a necessary part of our secure identity. That makes us lazy about them, and thus predictable and vulnerable.
So what is a better system for coming up with secure passwords? What Troy said can be summed up by this xkcd comic:
Needless to say I’ve since changed a bunch of my passwords.
#5: My girlfriend knows more than me about passwords
2 weeks ago my girlfriend was telling me what she got her sister for Christmas: a password book. Alarm bells immediately went off in my head: a password book? You mean you want to write all your passwords down in a book? Unencrypted? In plain text? All stored in one location? That’s insane! I quite blankly told her that it was a stupid idea, but that wasn’t very nice of me. (Sorry, Nat!)
Fast-forward to Troy Hunt’s talk. As part of the Q&A, someone asked him how they would go about helping their family members who refuse to acknowledge that their passwords are bad and should be updated for security sake. Troy’s answer was first of all to stop being IT support for your family. Great answer. The more serious answer was, lo and behold, to get them a password book! At this point, I’m losing it in my head, Troy freakin Hunt just said to write your passwords in a book!
Now its obviously not just for any password, but if you employ the password generation tactic as suggested by xkcd above, and then use a unique one of these for all of your different accounts, you’re left with a bunch of unique 4-word phrases, and then since that’s too much to remember, you write them down in the book!
This way, each of your online account passwords are as secure as can be, and any data breaches would not impact any of your other accounts! The only problem is of course if someone steals that precious book of yours, thieves tend to not pick up little booklets, especially if you label it as “recipes” or “phone numbers” or anything but “My Passwords <3”. Alternatively, Troy recommends to use something like 1Password.
So, lesson learnt? My girlfriend was right about passwords, I was wrong. Now I think she’s going to get me a password book for Christmas, but I don’t think I’m quite ready for that yet. Thanks a lot, Troy…
No Comments