Modern Infrastructure

Hybrid cloud command and control

peshkova - Fotolia

News Stay informed about the latest enterprise technology news and product updates.

How can vendors live up to user's software quality standards?

When it comes to enterprise software, quality is key. The software development process is lengthy, but vendors have a lot to consider when churning out newer versions.

Vendors are busy worrying about delivering cheaper, faster, better software, but IT professionals are more concerned with software quality standards.

Recently I saw a note about a survey of CIOs and cloud technologies. These CIOs said vendors need to move faster to add cloud features.

I also noticed a fan uprising against Apple. They were disgruntled about the quality of Apple software, claiming it felt unfinished, buggy and full of rough edges. Perhaps there is cause for concern, given the recent lawsuit over iOS space consumption.

Last, there's been a lot of talk about VMware missing its annual vSphere release. To some, it's the apocalypse. Others are more forgiving, suggesting that VMware is taking time to fix bugs, or is adding surprise features to vSphere.

So why do I mention these three things? Simply, they're symbols of our unrealistic expectations of software and product development -- especially when it comes to enterprise software vendors and the software development process.

Software vendors have a lot of things going on at once: They're developing new features for future versions of software, diagnosing and triaging bugs in released versions and attempting to do quality assurance (QA) testing on all of the resulting changes, ensuring they fix more things than they break.

Every version and release that a vendor supports makes all of these tasks much harder. Bugs found in one version are often present in others, and must be fixed there, too. The point of new releases is new features. But that means codebases are different. The code to fix the problem in one version might be incorrect for another, even if the same bug is present in both.

Then there's testing. Every change needs to be tested to make sure it does what it needs to and doesn't cause a regression or unexpected change in how the software works. QA testing and fixing bugs are hard for the same reason: too many versions with too many differences between them.

Metcalfe's Law states the value of a network is equivalent to the square of the number of connected users. With software development, we replace "value" with "difficulty of keeping everything in sync."

Pick only one, pick better

CIOs always seem to ask vendors for three things simultaneously: cheaper, faster and better.

Choose only "better." Better quality software is cheaper to install and maintain. Vendors don't have to spend all that time synchronizing communications about bugs if bugs don't exist. IT staffers can devote time to worthwhile problems, rather than spending time on the phone with vendor support. This is cheaper too, because time spent working through IT problems is overhead and wasted money.

"Better" probably means longer release times, but higher code quality, which will set a company apart. Hopefully that's what VMware is doing with its 18-month vSphere release cycle, and it is suggested for Apple too. Allow more time for the ecosystem to stabilize, for bugs to be fixed and for communication. Counterintuitively, it will likely mean faster adoption within organizations too, because users will put more trust in the releases. I wouldn't be surprised if the CIOs asking for "more features," "faster" are actually running ancient versions of software in their data centers, because those versions work.

Bob Plankers is a virtualization and cloud architect at a major Midwestern university.

Article 8 of 10

Dig Deeper on Managing Cloud-Native Applications

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I think if vendors provide a beta version they would get much needed real world feedback on the pros and cons. They would also get endusers doing the debugging for them. Users do not think like a program designer and have different views on how something should work. What might look good on the project board may not work well in the real world.
I would hesitate to call what end-users does as debugging.  Debugging actually implies the ability to trace through the code while you run it, maybe setting breakpoints, and evaluating variables as you go.  I'm not going to knock Beta versions, but what many companies lately have called Beta would give an 'Alpha' version a bad name.

I think with Agile principles, delivering small increments over time, that change can be embraced and issues about usability can be found much quicker however.
Yes, I guess debugging was the wrong word to use. It's more like them doing the quality testing and passing on the errors.
It concerns me that end-user expectation should be dismissed as unrealistic. I believe it is this wild expectation that fundamentally challenges developers to achieve quality.
I agree that the developer may not know all the intimate details of the industry. The is where the feedback comes into play. If developers knew every industry top to bottom we's have much more stable applications. That is a dream as the industries are changing constantly.
Much as organizations would like to believe that dog-fooding acts as a proxy for the customer, it doesn't. It gives a very narrow sliver of potential uses, and usually optimized for their approach and methods. Expanding to other external users, either as a b eta program or early adoption "free community" version can be very helpful to look at different models and approaches of use, as well as over all user experience. A/B testing is a good example of this approach.
One of the primary questions it comes down to is “does the software meet the reasonable expectations of the users?” The key here is reasonable. Companies need to meet those reasonable expectations, without unnecessarily reducing the value of the product to those users.
"When it comes to enterprise software, quality is key."

But quality is multi-dimensional, and not the same as meeting the expectations. I expected Vista to suck - it sucked.

In enterprises, purchasing decisions sometimes are made by those who are not end-users of the products, and not necessarily aware of their needs.

Get More Modern Infrastructure

Access to all of our back issues View All