The curse of software
Every IT consulting company I ran into had this thing in its sales pitch. Seems like that single characteristic is common to all of them. We are aware of the fact that sales have to sell, but it makes me wonder nonetheless. Is their biggest selling point the root cause of their biggest problems, at the same time.
What is the software quality, anyway? I still have doubts about what that means.
Before going further, I am aware that when piece of software written to support thousand of users suddenly gets loaded with requests from million of users, it will most probably fail. But that is not what I want to discuss here. I want to keep my thoughts about software that implements features its users need and use, without going into the question of scaling it up and out.
Software is not a physical thing. It cannot snap or crack. It’s not created out of material that get’s tired after many years of running in production. It can run forever and ever. This is why we can write shitty code.
Even if it is badly written, an application can run smoothly and be performant. Users will be happy with it as long as it does what they need. And nobody will ever notice that the code is bad and nobody will ever care.
Except people maintaining it. They will be concerned for the success of the business and they will keep saying “everything has to be rewritten from scratch” at the same time while they raise their concerns about time needed to rewrite the app because the code is so bad it cannot be properly refactored.
Maintainability is obviously one of the important characteristics of good and high quality software.
On the other hand, I’ve seen some source code brilliantly designed. Scalable, extendable, maintainable… But not user friendly. All functionalities were in place but counterintuitive. Engineers were proud of their product but users were not satisfied with it.
Usability is clearly another trait of high quality software.
Correctness too — nobody wants an app that is full of bugs. Nor do we want to use slow programs. We want our tools to be efficient and performant.
Are there some more requirements software has to fulfill before we can call it high quality?
Just googling “software quality traits” gives me:
so it seems there are six main quality characteristics in standardized software quality model.
We can go on like this. The more we think about software quality, the more our wishlist grows.
And this is where the curse shows itself. Academic and theoretical researches are clear on this topic, but it is very much ambiguous what “high quality software” means in real life. With tight budgets, close deadlines, fluid requirements, ever-changing teams of people and shrinking time-to-market, we are more than willing to forget what “quality software” should be and we use that term to advertise something else, something less.
Consciously or not, under pressure of fast paced business, we hide behind the ambiguity of the term, giving ourselves slack, cutting short where we shouldn’t and creating a product which is a wolf in sheep’s clothing. Sooner than expected, what once was a “high quality product” becomes a maintenance time hog, people grow frustrated and the whole organization slows down…
It is then when that we think: “If only software quality was a physical trait. We would measure it somehow and we would know better…”
