As a player in the technology software services world, we have always prided ourselves on having delivered robust and high-quality software solutions to our customers. Needless to say, quality comes at a hefty price and we have been lucky that our customers understood the same and were willing to both drive the quality goals as well as support us financially.

We are realizing that of late, there is a subtle change in the mindset of the customers, some of whom are technology startups. There is an urgency to get the first version out of the door with limited features and limited testing. The reasons are many:

1. Limited funding for the initial prototype
2. Uncertainty about what features will actually make it to the final product
3. Desire to obtain quick customer feedback
4. Short marketing windows

The quality risk is being passed onto the software services vendor, but not always necessarily with the requisite budgets to achieve a quality product. At the same time, any software solution today is a Lego-like assembly of a variety of tools and libraries, some of them open-source; and even perhaps an N-tier application that requires significant quality efforts in every tier. The cost of qualifying every aspect of such an application is quite daunting.

Consequently, it is not unusual now to find an abundance of poorly crafted solutions that lack consistency of behavior, lock up once in a while, suffer from poor performance, lack acceptable scalability, and of course, occasionally decide that they require a reboot of the underlying hardware. This led one of our senior engineers to quip “The world is running on beta”.

What should a software solution provider do in the current circumstances? Join the bandwagon and cut corners? In any case, there seems to be a certain level of acceptability for that 20% which is not completely kosher and would have required 80% extra cost to have undergone a proper implementation.

Or should there be multiple versions of a solution – a quick and dirty initial version quickly followed by a more robust version when the initial version achieves some level of customer acceptance and there is more funding available to support the quality efforts?

Perhaps some of the old paradigms are no longer optional and need to be integrated into the software development process:

1. Test-driven development, or design for testing as in the world of chip design
2. Correct by construction

We believe that quality testing itself needs new methodologies (in addition to the traditional tools and methodologies), some of which will be derived from the solutions to the very problems that current software is trying to solve – big data, machine learning, and artificial intelligence – almost akin to an Escher-like recursion where the algorithms implemented in some of the software being tested also determine how the software should be tested.

Author: Atul Prakash Agarwal
Photo Credit: http://inspirabox.com/ and http://unsplash.com