In the past two days I attended a party with Gas Station owners, and then a Yoga school. These two events gave me the material for this blog. So what do a gas station and a yoga school have in common? Both types of small businesses use software. What a revelation! To be more specific, in both cases I saw the room for improvements in software.
Actually, I started writing about gas stations eight years ago. Senior (literally) Java developers may remember the times when reading printed glossy magazines on software development was a norm of life. Eight years ago I wrote a series of articles under the category “Yakov’s Gas Station”, which was printed in Java Developers Journal. You can still find them online.
Anyway, during the party conversation my wife mentioned an episode at a gas station that happened a couple of years back. We live in New Jersey, which is one of two privileged states where people are not allowed to fill gas tanks themselves. You pull down to the pump and keep sitting in a car like a tsar. The gas attendent will come over and will do the rest. He started filling my wife’s car at one price, then changed the price (increased) on their large billboard, then came back to the car trying to charge this transaction at a new price. My wife didn’t agree, and after a short and colorful conversation she won (what’s new?).
Our friends (gas stations’ owners) told us that in New Jersey it’s illegal to continue pumping gas if the the gas station owner needs to change the price. The owner should stop operating all pumps, change the price, and then resume work. This is how it should work in theory. But in the real life, you may lose customers if they’d be asked to wait. I was surprised that the gas station owners didn’t see it as a big deal.
I started to tell them that there is a better software solution, which could be implemented allowing continue pumping gas and changing the price without affecting the customers who are in the process of getting filled. Software developers know that I was thinking of implementing proper synchronization locks that would freeze the price that was in effect when the pumping started. Why it was not done? Software architects didn’t care about these small business owners, which would accept that “This is how the system is set up and we’ll use it this way“.
Now the Yoga school. They sell various types of monthly and yearly memberships that would allow attending unlimited classes – as many as you want. The problem is that I don’t need this all-you-can-eat option. Going there twice a week it more than enough for me. Any other options available? Yes, you can purchase 10 sessions at a discount price and attend them on an a la cart basis.
Now we are talking! Can I buy these 10 tickets and share them with my wife? No, the system is not set up this way. Sure, they’ve designed the database linking these tickets to the members’s ID. It’s a wrong software solution again. Why not keep things simple? A ten-session ticket is supported by a single database table with two columns: tktID and RemainingSessionsCounter? The customer comes in, hands the ticket to the girl who scans or enters the ticket number into that computa, and the program decreases the counter. Simple? Yes. Good for the business? Yes. Good for the customers? You bet!
The problem is that software creators have to build their systems based on what the customers needs. Yes, the customer may not know any better, but what about you?
Four years ago I was a part of a small group of people who created a startup for automating small-scale insurance business – the agencies. Back then agents were using a mediocre software that was available. We had almost no knowledge about how the small insurance businesses operate. But we didn’t like what we saw. Insurance agents also didn’t know any better. Today, more than a 100000 agents across the country are using our software called SureLC. They are happy, we are happy.
Steve Job once said, “People don’t know what they want until you show it to them.” So if you are about to automate a business, don’t just have write software implementing existing workflows. Think about the customers, and when your next system will go in production, people will say, “Wow, we didn’t know it was possible!”