Mechanical Turks and Viewing Slots
For the back story on what and where the expression mechanical turk comes from, see 18th Century Chess Robot and Amazon Marketplace.
In this context I will refer to Mechanical Turk as a cost analysis between getting work done by a computer or getting work done by a human.
To provide some background. In our property technology software an estate agent can set viewing slots on a property, which a consumer can then book onto online. At present the agent must set day & time availability against every property. Some agents who let 40+ properties per month find this quite time consuming, and ask us to pre-set standard slots against all properties e.g. viewings 11am-3pm Tuesdays and Thursdays.
Bilal wrote a quick script to automate setting these slots. However this script required to be implemented manually every time a new property was put on the market and every 10 days (to set viewing availability for the coming 10 days).
Properties without available slots show a waiting list option that consumers can join to be notified when new times become available. We've discovered that properties without available viewing times receive 31% less viewing requests. Thus it's pretty important to have viewing times always showing on the property.
The ultimate solution to this problem is a viewing request feature. Consumers can request any time, or if viewings are set book directly in. (Level two of this feature is more complicated, for high volume properties (ones that receive a lot of enquiries e.g. student flats) once a viewing is booked all other enquiries should be pushed to view at the same time first, and then allowed to request an alternate viewing time second.)
To recap. We have to manually set a script to run in order to set viewing times across multiple properties, but want to build a feature that enables consumers to request any time.
Here in we discover the tricky business of decisions. To run the script on new properties every day takes up Bilal's time, and interrupts development. Not to run the script would mean the product didn't work. Maintaining the product blocks further development on the product.
Simple... automate the running of the script, so it doesn't interrupt Bilal's work flow! If that, dear reader, was your natural conclusion you're ready to launch a tech business.
So that's what we decided to do, Bilal used a neat Heroku (a web application deployment platform) plugin to run the script automatically every hour. Job done!
Alas... Down the rabbit-hole you go Alice... you've entered the beautiful world of product complexity. Automating the script over-wrote any changes to viewing availability that the agent had manually set... a full on nightmare.
So we can fix the fix with another fix. To re-write the script, and the automation of the script implementation, and to write the automated tests to alert us to any failures in the script should take only 2-3 days. It's time for a couple of tech laws to be pulled out from this narrative.
a) things are always more complicated than they appear.
b) 2-3 days really means 6 days (double all estimations).
Assume then that it will take 6 days to get this working reliably at scale. With interruptions to Bilal's time (strategy meetings, other bug fixes, training our new apprentice) this could likely extend to 10 working days. Thats two weeks.
Maybe this would be less of a problem if: there wasn't many other development jobs to work on; we were not looking at developing a new feature that would totally replace this process.
An insight into some of the other technical jobs that Bilal is working on & that constantly come up.
Recap - the question: add two weeks to develop a feature that we want to replace soon or continue to interrupt Bilal's work flow with manually running the script, slowing down development process.
Enter option three, our fantastic Mechanical Turk. We've recently added Ben to the team. The third option is getting Ben to check client accounts three times per day for new properties and then manually (not using the script) update viewing times. This is not scalable, but works in the short term.
Ben is with us on an apprenticeship scheme, looking at the economics the required salary for an apprentice is £3.40 per hour, (without disclosing salary we do pay Ben more than this!) where as a developer can be upwards of £75 per hour. The economic cost of 2 weeks development work to automate a feature versus getting someone to do it manually is fascinating.
For the cost of automating the feature in 2 weeks, we can pay to run it manually for 40 weeks (but with a scale limit). Running this process manually means all Bilal's development focus can get us to the better feature that will remove the need to set viewing slots & will still keep the product useful for estate agents.
Time and time again I get told of technology business ideas, but very few people realise that it is very expensive to automate using technology and human labour is still affordable and skilled. We won't be replaced by robots for a long time yet.
