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!”
4 thoughts on “What Gas Stations and Yoga Schools Have in Common”
Nice post again, Yakov! Tell me, do you use this method in “FaRaTa Systems”? I mean, you`re one from main persons there, so, do you check code/design of every project your developers doing and tell them: “Hey, guys, I suppose our client would this great feature but he just don`t know about it! Let`s add it and he`ll be happy! Is it costs extra work week for us? Doesn`t matter! Just do that!” Do you work this way? Thanks.
Our engineers work on two types of projects:
1. Our own software (SureLC), where my business partner, who runs this project makes sure that all decisions are smart and user-oriented. He’s smart, btw.
2. Consulting projects for other clients. In these projects we always offer the client our technical opinion – what we believe would be the best technical solution. The client may either accept or reject our suggestion based on specific circumstances/deadlines/politics/available resources. In case of rejection we don’t fight. The client’s reasoning has higher priority. But since we didn’t lie to the client, we can sleep well too 🙂
You said “The client’s reasoning has higher priority.”
Ok, so why you write about some may-to-be features in other projects with some criticism? (gas stations, yoga classes). Maybe developers who made those software had good ideas (your ideas?) in mind and proposed it to client even, but “The client’s reasoning has higher priority.” Or do you mean it`s client`s fault?
I’m writing about my observations. I don’t know why the gas station’s or the yoga school software was written this way. But this blog got you thinking and at the very least you’ll share your technical thoughts with the gas station owner. Lots of software developers don’t even care to do this.