Our customers pay to use the software we make.
But what if we had to pay each customer every time they encountered a frustration or bug? It doesn’t have to be much, let’s say $1 each time, but go with me here. What if you had to pay your customer when your software failed them? What would change about how you build and deploy your software and handle customer service issues?
This idea is fascinating to me because immediately our incentives would change from feature-itis (enticing people to buy our software because LOOK HOW MUCH IT CAN DO, IT CAN EVEN BURP THE BABY) to making software as solid as possible, and it exposes the rift that focusing on more features necessarily means less focus on stability (unless you have unlimited money, people, and time, which no one does, as evidenced by the number of software projects killed by google).
Take this a bit further, and imagine that in our world that that state of affairs has always existed and exists now. What software would be better in this brave new world? What software would be worse?
This idea scares me, it is dangerous and wil be included in some new Management drive, and future Management classes.
In a way, for most software products, it already is paid somehow.
If you have many bugs, or some big-impact ones, you pay in reputation. And even if the cost cannot be exactly measured, it will be much more than 1$.
Of course, some lesser important or smaller bugs or niggles are expected and allowed, but too many or too big ones might cost you dearly.
As a company and development team you can also not jump on every reported bug, because some are indeed less important than that new feature, or might even be solved by a completely new feature in the near future.
Others are reported by people who don’t exactly know how to use your application decently, so an action might be needed to improve the UX instead of changing a behavior that might please a handful of users but might annoy the other 99,9% of your userbase.
At my current assignment I think like about 99,9% of reported ‘bugs’ are mainly stupidities performed by the end-user and they somehow find it easier to file a bug report than to figure out that perhaps they used the wrong logon account or sth similar(internal employees).
But most companies I know or have worked for, took real and important bugs VERY seriously and tried to find a solution for them immediately or the next iteration at the max for lesser impact ones.
Being in the process of arguing with Webex over whether an option is a feature or a bug* , this sounds like a way for middlemen and lawyers to make a lot of money, while the customer argues over whether they should get a dollar. In the meantime, the developer stops developing and spends more time trying to prove they meant to build the bug and therefore should not have to pay a dollar.
* Feature or a bug?: If you set attendee chat privileges to “all panelists” in a Webinar, and they send a chat message, their chat message gets sent to all panelists. The setting, however, prevents any panelist/host from being able to respond to the person who sent the chat, they can only respond to “Everyone”. Good news! I can upvote to change this “feature” in their community, according to the first and second engineers assigned to my ticket.
I think this could actually be a good consideration for management. As Giorgio said above, there’s a cost paid. In an effort to get a product out quickly, we may cut corners in the data design or coding level. These can have huge implications when it comes to reporting, support, security, and flexibility for future changes. The cost in developer time will eventually have to be paid to correct the issues. The phrase “do it right” and “do it fast” are sadly seen as equivalent sometimes..
Scott Adams thought about this a while ago. It’s sure how things would go where I work.
https://dilbert.com/strip/1995-11-13
Why deliver bugs in the first place? The methods to ensure nearly bug free software have been available for many years. I helped develop some of them. There seems to be a strong aversion to complicating computing by applying math/statistics to its development.
Well that’s good for mathy people, but what about everyone else? Probably the last tool any dev thinks of for writing a bug-free web service is statistics.
There is a very strong aversion – because of the notion has developed that anyone should be able to program without sound training. If we applied this to, say, medicine (medical school is all well and good for those who like it but what about the people who are no good at chemistry and biology etc) I think people would notice the problem. But, the notion has arisen that programming does not need rigorous logical training, just knowledge of boiler plates. This notion needs to be changed. Say that to a non mathematical software developer today and they will be most affronted.
My previous job was nuclear-certified software, subject to Title 10 of the Code of Federal Regulations. If there was a calculation error in the software, we were legally obligated to formally notify all our nuclear customers about the bug (and there were response time requirements for fixing it). We were not explicitly paying the customers, but just sending the notifications cost the company a lot more than $1 per instance. While we had pressure to get things done to get new sales, we never had “do this crappy thing so we can ship”.
I have always tried to write my code with this approach. I have usually worked on heavily scientific and mathematical projects, and this has given me more of chance to do it than others might have had. The intention of my two software books was to promote this attitude in a practical sense. But, the modern software developer environment seems to run against the principle. I believe it can be done. And to me it is bizarre that it is not. But, I expect this is an unusual attitude today.