About Me

TL;DR

What I’m best at: Holistic system analysis

  • The decomposition of a complex system into its subsystems
  • The understanding of the inputs and outputs of each subsystem
  • The analysis and evaluation of both system and subsystem context

My unfair advantage: Training

  • BS Mechanical Engineering (University of Denver)
  • MBA (University of Denver)
  • MS Mechanical Engineering (Michigan Technological University)
  • A lifetime of getting things to work 1
  • Living abroad in strange circumstances 2

What I currently do: Identify and investigate risk pertaining to features (as those features are developed)

My Background

Two months into my first job as a software tester my colleagues awarded me the over-under-qualified superlative because I had earned two Masters degrees while accumulating exactly zero experience in what was ostensibly my chosen career.

After I finished my undergrad in mechanical engineering I chose to pursue graduate work instead of working really hard to land a job as a CAD monkey. I’d worked with graduate students who had explained the paths forward to me, so I settled on a PhD program. And the rest is history (but not).

I was taken with control systems (a few famous ones include thermostats, autopilot, autonomous vehicles, self-guided missiles, and rockets). Controls engineering is a sort of skin that can be applied to almost every other engineering discipline. The idea is to drive system outputs to desired states by manipulating system inputs. By abstracting the physics away I felt like a much more powerful engineer. I no longer needed to know how to solve the differential equation, I could just ask the subsystem to solve it for me and make a decision based on the solution.

After two and half years of stuggling, some ruined professional relationships, strained personal ones, and a general sense of worthlessness, I decided to move back to Denver. Within a week of making my decision and starting to plan my exit a close friend posted a job listing for a QA Specialist. I’d never heard of QA and never would have looked twice at the posting, except for the person who posted it.

I opened the posting, read it through, and immediately sent something very much like this: I know this doesn’t make sense, because I have two Masters degrees and you’re hiring for an entry level software tester, but what would you say if I wanted to come work for you.

They sent back: You’re right. That’s weird. Send your documents.

More serendipity ensued and within a month of my initial inquiry I was gainfully employed as a software tester, and the rest is history (for real this time). It’s been just over three years since my first day as a tester and I couldn’t be more grateful for the opportunities CK, my first employer, created for me.

I was CK’s first, and only, QA hire. While I was there the consultancy ranged from ten to fourteen employees and generated about $1.1M in revenue, per year. I’ve sanitized a couple of our projects below as a portfolio stand in.

From there, I was given a tremendous opportunity to work for CyberGRX. We build and maintain a third party cyber risk management exchange designed to help our customers manage their cybersecurity risk.

Contrived Example 1: Managing The Ball Park

Imagine you’re responsible for managing operations at Coors Field for the Colorado Rockies and, because this is a contrived example, the Rockies have chosen to reduce the number of third parties involved on game day. The vision is to no longer outsource security, ticketing, or kiosk management. Instead of running dozens of software platforms, the organization has chosen to build it’s own enterprise resource platform for game day operations.

It will include:

  • The source-of-truth for ticket sales
    • A two-way integration with TicketMaster
    • An admin UI to manipulate prices
    • An end user UI to purchase tickets directly from the Rockies
      • One set of permissions for purchasing tickets over the web
      • One set of permissions for selling tickets at the box office
  • A user interface for ushers to report messes or disturbances from their mobile devices
  • A user interface for pulling reports so that managers can understand what’s happening around the park in real time

Team Members: Executive Sponsor; Relationship Manager/Product Owner; 3 Web developers; 1 mobile developer; me

Build Time: 18 months (gross revenue: ~$1.1M)

Lessons Learned:

  • Do the hard work early in a project to get to know developers. Sit with them as they work. Test things together to understand the specific steps required to set up or tear down data manually.

  • If you invite your clients to the office for an after-hours launch, expect to have a late night.

  • When migrating large data sets, check the boundaries aggressively.

  • Advocate for testability early and often, especially when it comes to timed jobs on the order of days or weeks. To be effective testers we need automated triggers on the order of seconds or minutes.

  • I developed a regression testing template in Trello that could be copy and pasted to execute a specific regression testing cycle. Stitching the completed tickets into meaningful chunks of testable work made me the expert on the system.

Tech Stack:

  • Web: Ruby on Rails; React
  • Mobile: React Native (Android and iOS)

System Diagram:

TODO

Contrived Example 2: Metal Detectors At A Ball Game

Before entering a sporting venue, everyone has to pass through a metal detector. Imagine those detectors were capable of different types of scans. For each person that passes through the machine, the attendant has to click a user interface to select the type of scan, then wait for the machine to prepare for the cycle (by changing size, or sensors, or…something mechanical – I did warn you it was contrived). When the machine reports ready, the attendant waves through the patron, waits for the all clear, and then selects the next scan type.

Each metal detector is connected to the network and sends data pertaining to each run to an admin app. The data it transmits include: pass/fail, configuration, duration, number of runs completed since last repair, et cetera.

A boss is sitting in a backroom watching a dashboard of all the metal detector cycles happening right outside his door.

We built the software on the control panels, the data pipeline to the admin app, and the admin dashboard.

Team Members: Relationship Manager; Project Manager; Web Developer; C++ Developer; me

Build Time: 6 months (gross revenue: ~$450K)

Lessons Learned:

  • Technical documentation is about learning the product and communicating in pseudo-real time across the team doing the work. As its a learning tool, we should expect to update it as we learn more.

  • When hardware is involved in the end product, at least some of the tests should be executed against that hardware.

  • Software emulators and simulation can be effective tools for software testing.

  • Soap Opera testing is a fantastic tool for breaking out of the mental grooves we sink into over time.

  • To test the web app, I ran the front end and back end apps locally and clobbered data on demand. It was fun and made me more effective.

  • Data management gets difficult over time, when automated checks are involved. I had a directory of “active” tests that manipulated data state and a directory of “passive” tests that looked for UI components but didn’t create any data. It was a good first foray into writing automated checks.

Tech Stack:

  • Admin Web App: Ruby on Rails; React
  • Automated Checks: Cypress
  • Control Panel: C++

System Diagram:

TODO

  1. I’m the co-author on three peer-reviewed engineering papers. In all three situations I was a scrappy student asking for enough help to get off the ground and then stubbornly driving towards a solution. Before that, I worked with my dad to maintain our home’s industrial sprinkler system. Before that, I built hundreds of lego sets exactly by the book. ↩︎

  2. I studied abroad in Lancaster, England. At the end of my first week there I broke my left foot; I knew no one. I was on non-weight bearing crutches for the duration of my three month stay. A couple years later, I took a job as an English coach for Brazilian high school students. My teammates and I leveraged video conferencing and built online curriculums before our one month trip to teach intensively in Ponta Grossa. ↩︎