A Lesson - 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 difinitively works.
While good motivation — proving validity of the solution for complaince 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:
- A daily SMS report showing Customer’s revenue using our tool. ([Some twillio action!][twillio-blog])
Your Daily Report 09/09/2018 --------------------------- ...........Tests........... Total : 17 Location 1/Location 2: 11/6 Rev @ $75 : $1275
- 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.
I needed a plan of action — and to put the UX work into statis.
20 new records a day. 40 fields per. 6 days a week.
In about 2 months, gsheets tipped past its threshold, and exponetially 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.