Virtually Possible (a tale of iterative creation and remote teamwork)

Printing Machine goes Brrrrrr!!!!
<pushes in glasses to deliver lengthy explanation>
  1. How do we replicate the steps a paralegal goes through to assemble their data before creating a document?
  2. How do we capture a generated document?
  3. How do we compare the generated document with an expected result?
  4. How do we communicate the results?
  5. How do we enable our team to take action on the results?
  6. How do we run this process repeatedly?

How do we replicate the steps a paralegal goes through to assemble their data before creating a document?

Watching a paralegal at work (our point of view).

How do we capture a generated document?

I guess we don’t need the previous code anymore!

How do we compare the generated document with an expected result?

The magic incantation

How do we communicate the results?

Yay! All passing!
A bit of redaction. We don’t want to tell all of our secrets ;)
Oh yeah! That side by side makes the work glide!

How do we enable our team to take action on the results?

Yes, we wrote it, but don’t ask us how it works.
All is well, and then a test breaks.

How do we run this process repeatedly?

Probably wise to tidy up at some point, but it works!
You win some. You lose some.

Problems left to solve

  • Pipeline optimization and test parallelization
  • Adding more test cases
  • Consensus on handling branches generated by diff errors
  • Make more widely available to run on other development environments.
  • Applying to SVGs (for testing app generated org-charts. oh la la!)
  • Applying to PDF’s (for testing app generated docs, but are PDFs rather than .docx)
Our team hard at work!

Our biggest learnings

  1. Motivation and Discipline. We found that a great way to get through some challenging issues was to book working sessions with our team working remotely. Even if only one person was coding for a part of the session, it was a great way to stay connected and motivated. It was also a great way to keep focused on the end goal #Focused-creatives.
  2. Tool research. Our initial discovery on what to use brought out a zoo of options (Jenkins, Selenium, etc.) that we had to sort through. We approached this decision by comparing and scoring each to how well they answered each of our initial questions. After lots of reading and searching, we were able to come to a decision #Ambitious-learners.
  3. Identifying checkpoints and audiences. We were fortunate that we had several opportunities to show off our stuff as we built it. Our scrum master started a show and tell session that was invaluable for discussing new ideas! #Diligent-builders.
  4. Being highly iterative. We were thrilled that we could produce a proof of concept that was also easy to continue building on. We found it way better in the long run when we didn’t over plan things and started playing with tools.
As they say, “build the skateboard before building the Tesla.”

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Shane Fast

Shane Fast

Co-founder of Athennian @athennian. Always interested in hearing from entrepreneurs, colleagues, and self-driven people.