A mandatory ingredient to business survival!
Would you pick an airline that claims:
“We are excellent at take offs, kinda good at landings and we think our mechanics are mostly ok.”
Of course not, even if the price of a ticket is a lot better than a competing airline.
Why is this? Because your life depends on it of course. Landing is kind of important… We will accept less comfortable seats, longer layovers and reduced inflight services if the price is right but we expect excellence from pilots and mechanics; no compromises are possible there. You don’t need to think about it much, this is pretty intuitive. Crashing is not good for your life expectancy. Excellence is thus expected when your survival depends on it… That’s easy!
What about your business survival? In what exactly should you excel to preserve your corporate health and even existence? Among many obvious things, there is one extremely important metric that businesses tend to overlook: software quality.
In the past, the consequences of writing, delivering and using low quality software was not necessarily catastrophic or business threatening. Not anymore. Consistently writing high quality software is becoming as fundamental for a software company as always landing a plane safely is for any airline company. Here’s why.
In the past, bad software did not kill many businesses for three main reasons:
- Software makers had many tries to “land”. For years it’s been OK to “land” bad software in Production. User Acceptance Testing and the Pre-Production environments would let the customer catch some of the bad stuff. A lot of the QA burden was accepted by the customer and expected from the vendor. Long “stabilization” periods were the norm.
- Everyone was equally bad. Even the big ones were guilty. Oracle, SAP, Microsoft and others would release buggy code without second thoughts. I just have to recall my ERP implementation days... upgrades were supposed to be painful and costly. We all knew that…
- Customers accepted bad software anyway. They would sometimes complain but, captive as they were, customers would continue to pay insane amounts for licenses and support fees. Every once in a while, a “patch” would be released. Sometimes the patch would break more things than it would fix. Oh well, there would be another patch for that!
The situation is different today.
“As daily software users, our expectations have changed.”
Whether it is a business solution or a device firmware, our tolerance for digital failure has gone down dramatically. We also expect high availability, performance, scalability, competitive costs and we want upgrades to be continuous and transparent too!
As an example, I use Google mail both personally and professionally. It is always available, new features or corrections become available without any “upgrade” process and it’s inexpensive. The corporate systems I use such as time sheets, billing and accounting solutions are like that as well. As a user and a customer this is how I expect software to be now. There is no going back to the old ways.
To be able to meet these new expectations, software makers have to release quality code consistently and frequently. In the case of multi-tenant SaaS solutions, since all customers use the same code version, the ability to deliver new features that can scale across large user communities without creating regressions is of paramount importance. Solution providers need to land on the first try.
Writing and delivering quality software is not trivial. No longer is QA a stop at the end of a linear software manufacturing track. Today, quality must be embedded and automated in the software engineering process. Concepts such as Test Driven Development (TDD), Continuous Integration (CI) and Continuous Delivery (CD) are key. It requires from development teams to master a more complex development and delivery ecosystem. The good news is that it surely can works! The bad news is that it is more complex and requires skill sets and a mindset that may not exist in your teams today.
If I had only two pieces of advice for someone planning to depart from a traditional approach to software development and join the world of TDD, CI and CD, they would be:
- View it as a revolution rather than an evolution. Evolution suggests some degree of continuity between the initial state and the end state. In this case, there is no real continuity. Pick an initial project, small but with real impact, and make a first success. Use the success to influence others in believing it can work and bring benefits.
- Get help. Seek assistance from credible people who have done it successfully in the past. Implementing a complete ecosystem, embracing new architectures, processes and coding techniques can be overwhelming. Someone with experience will definitively increase your chances of success.
High quality software is an absolute pre-requisite of high development velocity, which in turn is necessary for innovation… Like those long lived bridges, quality is now required to preserve your corporate health and even your existence.
Be the Revolution!
by Denis Brochu, founder at Ingeno
Learn more about us at ingeno.ca.