A Lesson - Technical Debt

Using Google Sheets for prototyping launched a boomerang of technical debt.

A chunk of technical debt smashed into the project like an extinction level event just after User adoption.


The Cause (per usual): Clever, Clever Me

Using Google Sheets for prototyping launched a boomerang of technical debt.

The Customer always wants to see all the data, and to prevent building an admin interface straight away I thought to wire everything to Google Sheets.

They already used a gsheet or two as part of their existing workflow, and research showed plenty of articles on methodologies.

Off I sprinted with semi-good info to prototyping.


Motivation: An Instant GUI

By exposing data in real-time using a Google Sheet as a makeshift, instant admin interface, I figured this could show the Customer: the solution definitively works.

While good motivation — proving validity of the solution for compliance software to the first customer — another, probably perpetually better solution: start with proper reporting.

Better: Proper Reports

Creating well-defined and well-delivered, lean-as-possible reports proved fast and easy.

We chose and now use:

  1. A daily SMS report showing Customer's revenue using our tool. (Some twillio action!)
		Your Daily Report
				09/09/2018
		---------------------------

		...........Tests...........
		Total : 17
		Location 1/Location 2: 11/6
		Rev @ $75 : $1275
  1. A weekly email report showing daily and weekly Customer revenue for the week plus the cost of our tool.

Motivation: Same Tooling

By matching existing workflow tools, I reckoned User and Customer adoption would be easier.

Reality: Who Cares. Make it Work.

User adoption happened because their job was easier. Users don't give a damn about technology, nor should they.

Customer adoption happened 98% because Users were happy.

I could have used a db browser to show accurate data and that would have been enough.

Hey, is This Slowing Down?

As I prepped for a new release focused on UX, an Examiner pointed out how slow things were running.

One component, a Chrome Extension for Examiners, prevents mis-typing by automatically typing validated data into official forms.

At the beginning of the week, hitting the backend took 2 seconds. By Thursday, about 2 minutes.

I tested an hypothesis: G Sheets cannot handle the load.

Yep.

I needed a plan of action — and to put the UX work into stasis.


20 new records a day. 40 fields per. 6 days a week.

In about 2 months, gsheets tipped past its threshold, and exponentially ground to a halt over about 10 days irritating everyone who touched it.


Over 3 days I whipped up a proper database, re-wired the services, took advantage of the one day of the week the shops did not open, and tested a deployment which improved everything by a near infinite amount.

On Monday everything was super fast, at least as accurate, more secure, and Users were happy.

I returned to the UX release and had it out pretty quick after this major upgrade.


The Short Answer: Always Start with a Database or Two.

While G Drive Might Work Fine for Settings and Preferences...

...relying on it for a db growing at happy-beta-User levels of adoption may boomerang.