Monthly Archives: October 2012

A Solution Exists

Posted on by
Reply

I’m reminded of an old, very geeky joke:

A mathematician, a scientist, and an engineer all take a room at a hotel.  They each wake up separately to discover a small fire in their wastebaskets.

The scientist sits for a minute, calculates the amount of heat being created by the fire, determines the amount of water required to put it out, fills up his ice-bucket to that precise amount and tosses it on the fire, putting it out.  There’s no excess water and the mess is minor so he goes back to sleep.

The engineer looks at the fire, grabs the ice-bucket fills it to the top with water, figures there’s more than enough water in it, toss it on the fire with a margin of water to spare.  The fire goes out and he goes back to sleep.

The mathematician looks at the fire, looks at the ice-bucket, determines a solution exists and goes back to sleep.

When solving a problem, sometimes knowing a solution exists (or doesn’t exist) is half the battle.

I’m currently trying to win a programming contract to update a gentleman’s website. One of the requirements may be to integrate with some sort of payment service.  So, some quick research showed such a solution “existed”.  I had achieved the level of mathematician.  The service suggested is  Paypal’s https://www.paypal.com/ipn service. 

But it’s one thing to show a solution exists, I had to actually work with the solution to make sure if the time comes, I can implement it.  So, spent a few hours tonight working with the code example provided by Paypal and a database I created to test the proposed solution. After a couple of minor errors, I was able to use the test sandbox to call my callback URL and record the responses to the database.  I had achieved the basics. But this was also the hardest part.  So I have achieved the level of scientist here.

Now, if the customer gives me the go-ahead, I’ll have to expand the code to actually parse the request string and other details and integrate it with his code and database.  That said, that part is actually fairly trivial in many ways as I will control the entire process there.

So I haven’t quite achieved the level of engineer, but if the time comes, I will.

So that fire is out.  On to the next one.

QuiCR’s latest product

Posted on by
Reply

I mentioned in my latest post I was working on a new project, one that valued simplicity over complexity.  I can now talk about it a bit more.

I had approached a local cab company about the QuiCR product.  Unfortunately, given who his largest market demographic was, (most of his fares do not have cell phones, let alone smart phones) we decided it wasn’t a great fit.

But, as I mentioned, he had made an off-hand comment about something he would like: namely an ability to allow a smaller demographic of his, the local college students, the ability to send a text to his dispatcher and request a cab.

This is one of those design ideas that’s both deceptively simple and complex at the same time.  It’s simple because “Receive text, display text, allow a response” about describes the problem.

Now, the simplest solution obviously would be a to give the dispatcher a cell phone with texting capabilities.  That would also be the wrong answer.  For one thing, his dispatchers work at a frantic pace and time is off the essence.  While some folks may be able to whip off text messages using “text-speak” in seconds, his staff isn’t among those with fingers that nimble.  

It also doesn’t provide for easy reviewing of messages and threads and the like.

So, the trick was coming up with a computer interface that was simple enough that it could be adopted with only a few minutes of training and that wouldn’t interfere with their current manual dispatch system.

The keyword there is manual. Yes, there are systems out there with all sorts of bells and whistles that can integrate with GPS, credit card systems, IVR and much more.  Those systems also costs a LOT of money.  And in at least one case, a vendor was suggesting that to adopt it, he hire another dispatcher to handle the increased load.  Note the load wasn’t necessarily from increased business, but simply from the complexity of the system.  Now, don’t get me wrong, in a large city where you have dozens of cabs, such a system is the right approach and scales well.  But, it doesn’t scale very well to smaller companies.

His dispatchers use a very manual system.  And it works. Hopefully my new “text-dispatcher” will integrate well with the current system and generate some new business for him.

Sometimes, simpler is better, but harder