Has all software just become beta?

I am sorry if this blog post sounds like a rant. I was looking for the non-rant button on windows 10 and then the whole thing froze and I got the blue screen of death.

blue-screen-of-death-windows-10

I recently updated the majority of the software I use in in my daily life at Inverted Software. Windows, Office and Visual Studio. There was a moment in time, when all the visible bugs in the old versions were fixed and stuff just worked. Of course, then the marketing machine that is Microsoft just went ahead and convinced me that everything I have is obsolete and new and amazing software is just around the corner. I couldn’t wait to update to the latest and greatest. You might call me an early adopter, after all, I still have an Archos 5 in an old drawer somewhere that I just had to have, back in the day before Android/iOS tablets came along Not to mention a first gen iPod I recently gave away.
Updating to the new versions created a huge amount of bugs and started an endless cycle of going online, figuring out solutions, making trips to the computer’s registry, patches, service packs, reboots and renewing my faith in God. (Praying that stuff will work when I am at a customer presentation or on the phone has proven to be a futile strategy, but, that is a subject for another blog post altogether.)
But then, as a customer was asking me to release a patch prematurely, because they needed it for an investor presentation, it dawned on me: Are we in a constant state of beta? Is all software always at 0.9? How did we get here?

It’s easy to release software today
Most software these days is SaaS, or self-updating, and the processes of releasing a new build to the cloud usually just includes a click of a button, or in the case of continuous delivery, just checking in new code. There is no physical media in the form of DVDs to duplicate, licenses to email out – large downloads no longer present a bandwidth issue.
As most builds happen in the cloud, when gated code is pushed and merged between branches, and there is always a running version ready to go into production.
Shorter QA cycles might take place to meet deadlines and smaller bugs might slip through the cracks with the expectation of the QA process still taking place after the initial release and bugs being fixed in patches.
The entire Application Lifecycle process now includes, so it seems, the release to production somewhere towards the end of the QA process, along with additional releases that are tied into expected bug fixes.
At this point, a patch is nothing more than a code checked in by a release engineer. Or even a developer.

Innovation driven release cycles vs. business needs release cycles
In a 2012 Cap Gemini study of 260 organizations, 43% of respondents said they had a Chief Innovation Officer or similar, up from 33% the year before.
What does it mean to have an innovation officer in your origination?
The innovator role was pioneered by none other than Steve Jobs. It’s the type of role that requires a combination of vision, market research, technology understanding and a pioneer spirit. An innovator would rather ask for forgiveness then approval. They will continuously push the envelope and redefine what’s possible, often frustrating engineers, but always putting a grin on marketer’s faces.
Innovators and marketers usually work hand in hand to create hype around new product features and releases, and will often commit to a release date even before the product is ready or tested.
“To write perfect software you need an infinite amount of time” is a phrase often used in the innovation world. So if the product you are using is innovation driven, expect to find bugs.

The hype
The hype is the marketing machine in action. It could be an email or a press release your ERP Company might send out, or an article in a magazine, explaining why the new phone that is about to be released is much better than anything out there, and is solving some of the major issues your current phone might have. Of course, these issues were not mentioned when the same magazine reviewed your phone when it was new.
The hype often meet the expectations in features, but, might not meet some of the quality tests.
The marketing department will always try and sell a slick, sexy, product – the kind you would want to keep updating. Reliability might not bring customers. Saying “Our product is bug free and works as advertised” is generally not as effective a marketing campaign as: “Our product has all these features and benefits and that’s why you need it”.
Sometimes the hype is hard to resist and it will have you replace software that works with one that looks better, but, still needs refinements.

Who built your software?
Cheap labor is everywhere. They say that, “the bitterness of poor quality remains long after the sweetness of low price is forgotten,” but, the reality is that a great deal of software these days is written by low cost developers in developing counties. Try as they may, an executive sitting in Beverly Hills can never know ahead of time what type of product his offshore team will produce. Butfixing poor quality products is an expensive operation. More than building them from scratch. Here at Inverted Software we believe in personal growth and our teams are hand picked and trained.

Software complexity in the SOA world has evolved
The science of testing software has progressed by leaps and bounds. Methodologies include Black box testing, Integration testing, Functional testing, Sanity testing, Regression testing, Acceptance testing and more.
Testing a modern system is a complex task and some bugs will go uncaught, however, that should be the exception. Never the rule.
A good QA process takes time, and the business should understand the value of releasing a product that works as advertised.

Did we make our users beta testers?
I hear it all the time: “My customers will let me know when they see a bug.”
Yes, they will let you know. They will also ask your competitor if they have the same bug and try out their software as well. Eventually they will get tired and leave. They are not married to your product and if you think the fact they already entered all their information into your system will prevent them from terminating your service, you are misguided. When you create a pain point for someone, they will tolerate it up to a point and then try and eliminate the pain point. In this case, that’s your software.

Tolerance for bugs
I don’t know when exactly this happened, but, I find that more and more users tolerate bugs in their software. More than tolerate, they actually enjoy finding them! In essence they like playing the role of QA in the process and enjoy reporting them back to the company. They will tell me with pride how they found a bug and made the company fix it!
Last week I was visiting with a potential customer that was clearly very busy. They are an auto repair shop. But they had stopped their work to show me, with pride, all of the bugs they had found in a mobile application that was designed to help them (not ours, by the way…). Finding and reporting these bugs actually made them feel important. They were able to identify with the product and brand, and felt that they were helping to make it better.
That’s great – those guys are the best type of customer. But if those bugs they reported don’t get fixed quickly, they can easily turn against you.

The last 10 percent of stabilizing software takes 90 percent of the time
Yes it’s true. Writing functional code is easy and rewarding. Making it bulletproof is difficult, time consuming, and boring. As a developer, wouldn’t you rather just transition to a brand new project where you can work with a blank canvas again?
As a business owner, when you see the system up and running, in your mind it’s done and ready to ship.
In reality, its only 90 percent done, but the rest may take a while. Acceptance testing might reveal extensive UX changes and even if for you it’s just moving a button across the screen, for the developers it could be hours of work, and three new bugs that where created in the process.
Most of the bugs that go out with new releases were created by 11th hour changes.
Know when to code freeze.

Conclusion
Here at Inverted Software we have been creating software for years and the best advice we give our customers is be patient. Don’t rush it. Trust the process. The end goal is to create great software that works great and keeps your users happy!

Contact us today and let us know how we can help with your software needs
Email: contact@invertedsoftware.com
Phone: 818.262.8552

One thought on “Has all software just become beta?

  1. The assumption that “My customers will let me know when they see a bug.” is quite wrong – How many bugs have you reported to Microsoft, LinkedIn or Facebook?
    Most of us will not report issues unless these are critical for us, and/or we are encouraged to give feedback by clear links which do not require too much effort in doing so – and preferably some prize.
    We do not report bugs to companies who collect too much information on it, as we care for our privacy,
    And we do not report to companies who reply with laconic messages, and as we see previously reported issues were never handled.
    So if 2% of the bugs users see are actually reported – we can be thankful.
    While users as you stated became more tolerant – they will think less of your product, and you can see that in vast amount of rants over twitter, which can lead to other users ignoring the product – even if you do handle these (assuming the company tracks these as another way for feedback)
    @halperinko – Kobi Halperin

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s