The Harajuku Moment

On a chapter from Timothy Ferriss‘s book titled “The 4-Hour Body“, he talks about something significant called the Harajuku moment, described as:

.. an epiphany that turns a nice-to-have into a must-have.

The expression actually came from a realization Chad Fowler (programmer, writer, co-organizer of RubyConf and RailsConf) had in Harajuku with friends some time in the past, while window shopping and lamenting how unfashionable he was. He noticed the tone of helplessness in his own words as he talked about his obesity, and felt angry at himself for being an idiot who went with the flow, making excuses, for many years.

After that defining moment, he turned things around and lost nearly a 100 pounds.

Two years in a row of annual physical exams (2015-2016), I was told that I have hypertension. The previous years I also felt that I tire quickly, becoming more so as the days went by. I’m just over 30, skinny, and believed that I should still be in my prime but was not. I wondered why things turned out the way they did, and eventually recognized that existing habits did not help me become the healthy person I thought I was.

I’m now performing weight-lifts and body-weight exercises 4 times a week, and is in my best shape in the past 10 years or so. What’s interesting is that making the change was actually fun and somewhat easy, very unlike the grueling and exasperating experience I initially thought it would be. I plan to keep things up, gaining as much strength as I can and keeping body fat percentage minimal.

What the Harajuku moment tells us is that, often, on most days, we have insufficient reason to take action. We only have nice-to-haves. We tell ourselves it would be nice to get fit, go on a date with that someone we really like, have a well refactored code, travel internationally, or learn a new skill. But the nice-to-haves do not give us enough pain to move forward. That’s why we sometimes feel we’re stuck in a rut.

Our nice-to-haves must first turn to must-haves before we can take advice and act.

Advertisements

Running Application Audits with Lighthouse

It was only recently that I was made aware of Lighthouse, a relatively new tool for running notable audits for web apps. It’s an open-source tool from Google, and can be found inside Chrome’s DevTools under the Audits tab.

Here’s what it looked like when our team tried it on a recent project (click GIF for a full view on another tab):

Running Audits with Lighthouse

The results:

Accessibility, Best Practices, and SEO Audits

Apparently we did good on accessibility, SEO, and best practices. We don’t usually test for these things, but it’s nice to know that we do enough on them. The application running on localhost wasn’t configured to run on HTTPS yet so it’s about right that we failed that audit for best practice. It’s also true that our app was designed to have small font sizes.

Performance Audit

What’s interesting to see was the dreadfully poor app performance. Throttling our page on a mobile device with 3G connection, it took at least 20 seconds before anything appeared on the page. That’s not good.

And some culprits:

Performance Audit: Opportunities for Improvement

It seems we can do better with our images and style sheets. And it also looks like our JS takes too long to boot-up. We don’t exactly do high-detail performance testing at work so it is awesome to have such a quick audit report from within the browser that notify us about such issues early. At least we’ll know the areas where there’s room for improvement right away.

There’s no excuse to not testing performance (as well as SEO, accessibility, and best practices) on a web app anymore, as far as tools are concerned.

Five People and Their Thoughts (Part 6)

Some engaging articles I’d like to share today:

  • The Failures of ‘Intro to TDD’ (by Justin Searls, about classic test-driven development, code katas, what TDD’s primary benefit actually is, mocks, and discovery testing)
  • Branching is Easy. So? Git-flow Is Not Agile (by Camille Fournier, on Git, tooling, teams, developing software with agility, how easy it is to create feature branches with Git, and some reasons why you don’t need it)
  • What’s Wrong With Estimates? (by Yorgos Saslis, about estimates, why we are being asked to provide estimates, and the pitfalls of the ways we are using them)
  • A New Social Contract for Open Source (by Eran Hammer, on open-source, free code but paid time, sponsorship, making clear rules and specifying benefits, and sustainability)
  • Introducing Example Mapping (by Matt Wynne, about conversations to clarify and confirm acceptance criteria, feedback, colored index cards, and the benefits of writing examples when exploring a problem domain)

Exposing Local Apps Publicly with Ngrok

Here’s a screenshot of something we’ve currently been working on:

It’s not available publicly yet, because it’s still in the early stages of development. The app, hosted locally on http://aspen.reservations.com/#/stay-dates, will redirect to a 404 page unless you have the app installed in your machine. As a programmer, the changes I’m making on the app is only accessible on my local computer. Other programmers will only be able to view the changes I’ve made if I push said changes and they download those updates on their machines.

Similarly, I’ll be redirected to an error page if I view the said app on my phone:

What if a tester or a product owner requests an impromptu demo of the app? What if they want to test it as is? Early constructive feedback is always nice. We can set up the app on their machine, but what if they’re working remotely? I’m pretty sure it would be a pain for them to install the development environment on their own. And what if they want to test it on their mobile phone? Having the environment installed on their computer doesn’t mean they can test the app on an actual phone.

Apparently there’s Ngrok. It’s a quick solution to publicly sharing local apps over the internet.

Here’s a screenshot of me trying out the free version:

And now I can test the app on my phone!

No installations needed on the tester / product owner / client side, just a single bash command from the programmer instead. So cool!

 

A Design Problem

This weekend, while in the middle of a deep dive into the practice of discovery testing on a personal project, I realised that there are different ways of building software from the ground up. That’s actually obvious because there are various programming languages and there are tons of frameworks for quickly constructing apps and sites. It’s literally never been easier to write software from scratch. But simple to start doesn’t mean that what we create turns out to be something that’s easy to maintain or extend, even if the team decides to write more tests or use more tools to monitor the sanity of the codebase. Even if user stories are clear and there’s enough capacity for testing, it can still be difficult to deliver changes without a hitch and on schedule, when the code makes it hard to do so.

For many testers and product owners who have never before looked at the code that runs the apps they test, it may be tough to see how simple feature requests take too long. It can be mind-boggling why bugs continue to creep in. We tend to just accept things as is. Finding out why is one reason I learned how to read and write code myself, besides the desire to have better communication with the devs I work with and having the ability to write my own tools to augment how I test. And after having been writing test code for a number of years now I can say that translating ideas into new code can be easy, but revising existing code to accommodate new business rules is often  troublesome. That means, at least for me, that I have a problem about the way I am writing code for the long haul, even if my app is working at present. I can imagine other programmers having the same predicament.

I now understand that writing long-term, maintainable, software is essentially a design problem. And it seems that a lot of us needs to up our skills in that area.

Bumping Into Discovery Testing

Until recently, what I mostly knew about test-driven development was the concept of red-green-refactor, unit testing application code while building them from the bottom-up. Likewise, I also thought that mocking was only all about mocks, fakes, stubs, and spies, tools that assist us in faking integrations so we can focus on what we really need to test. Apparently there is so much more to TDD and mocks that many programmers do not put into use.

Justin Searls calls it discovery testing. It’s a practice that’s attempts to help us build carefully-designed features with focus, confidence, and mindfulness, in a top-down approach. It breaks feature stories down into smaller problems right from the very beginning and forces programmers to slow down a little bit, enough for them to be more thoughtful about the high-level design. It uses test doubles to guide the design, which shapes up a source tree of collaborators and logical leaf nodes as development go. It favors rewrites over refactors, and helps us become aware of nasty redundant coverage with our tests.

And it categorizes TDD as a soft skill, rather than a technical skill.

He talks about it in more depth in a series of videos, building Conway’s Game of Life (in Java) as a coding exercise. He’s also talked about how we are often using mocks the wrong way, and shared insight on how we can write programs better.

Discover testing is fascinating, and has a lot of great points going for it. I feel that it takes the concept of red-green-refactor further and drives long-term maintainable software right from the start. I want to be good at it eventually, and I know I’d initially have to practice it long enough to see how much actual impact it has.

Favorite Talks from Agile Testing Days 2017

There are two things that’s wonderful from last year’s Agile Testing Days conference talks: content focusing on other valuable stuff for testers and teams (not automation), and having as many women speakers as there are men. I hope they continue on with that trend.

Here’s a list of my favourite talks from said conference (enjoy!):

  • How To Tell People They Failed and Make Them Feel Great (by Liz Keogh, about Cynefin, our innate dislike of uncertainty and love of making things predictable, putting safety nets and allowing for failure, learning reviews, letting people change themselves, building robust probes, and making it a habit to come from a place of care)
  • Pivotal Moments (by Janet Gregory, on living in a dairy farm, volunteering, traveling, toastmasters, Lisa Crispin, Mary Poppindieck and going on adventures, sharing failures and taking help, and reflecting on pivotal moments)
  • Owning Our Narrative (by Angie Jones, on the history of the music industry so far, the changes in environment, tools, and business models musicians have had to go through so survive, and embracing changes and finding ways to fulfil our roles as software testers)
  • Learning Through Osmosis (by Maaret Pyhäjärvi, on mob programming and osmosis,  creating safe spaces to facilitate learning, and the power of changing some of our beliefs and behaviour)
  • There and Back Again: A Hobbit’s/Developer’s/Tester’s Journey (by Pete Walen, on how software was built in the old days, how testing and programming broke up into silos, and a challenge for both parties to go back at excelling at each other’s skills and teaming up
  • 10 Behaviours of Effective Agile Teams (by Rob Lambert, about shipping software and customer service, becoming a more effective employee, behaviours, and communicating well)