3 ms·
10 years back when I was first starting my company, we wanted to build a phone IVR system with Twilio to book tables at restaurants. It was fairly complex; it t
by dudeinjapan 5y ago
10 years back when I was first starting my company, we wanted to build a phone IVR system with Twilio to book tables at restaurants. It was fairly complex; it to track many different aspects of call state, including client being able to enter things like date/time/party size etc. with push-dial, and call our internal APIs. I assigned a recent college grad to the task.
In a week, she came back and said "OK I've finished the prototype." I thought no way and I asked her to demo. Try X, try Y, try X + Y, etc. -- it all worked.
Then I looked at the code.
She had written the API handler as a one gigantic function, presumably because Twilio gives you a single API callback on an incoming call. It was a maze of nested if-statements going 10+ levels deep, subroutines relentlessly copy-pasted inline throughout the whole thing. Then she manually tested by dialing the phone 100s of times, putting in hacks throughout the if-tree.
Her prototype ended up being pretty easy to refactor and was ultimately the basis (at least logic-wise) of what we put into production.