A few days ago I came across a blog post, by Valentina Cupać, titled “Are bugs and slow delivery ok?”.
The title itself was enough to irritate me. What do you mean? That’s been an answered question for decades! Surely this is nothing more then clickbait.
Reading through the post, my irritation grew into real anger.
In the post (which is short and well-written, well worth the read), Cupać asserts that, indeed, bugs and slow delivery are OK.
Based on her experience, most companies can afford to ship buggy products, slowly.
Bugs have low impact on the business. The speed of fixing them doesn’t matter much.
Making developers miserable due to a constant stream of “urgent” bug fixes is fine.
As a proponent of such noble ideas as TDD, trunk-based development, refactoring, etc, you can see why Cupać’s ideas would be hateful to me. It’s the exact opposite of everything I believe in!
But there was one thing that I hated most about her blog post:
She was right.
Cupać says that she came to her conclusion based on her personal experience.
That made me reflect on my personal experience, in the last 15 years of working in software.
I’ve seen (and wrote) some terrible quality code. Really bad stuff. Untested, most of it.
In nearly every place I’ve worked at.
I’ve seen enormous amounts of time wasted with testing for, or fixing, bugs.
You know what I haven’t seen? not once in 15 years?
A company going under.
I’ve seen expensive and unnecessary re-writes, once technical bankruptcy was inevitably declared.
I’ve seen developers burn out by being regularly pushed to work all hours to fix bugs.
I’ve seen my product colleagues scramble to sooth, explain, and yes – sometimes downright lie, to customers, about why features are late.
But none of that caused these companies to go out of business.
And why is that?
I think the answer lies in this uncomfortable truth:
Software doesn’t make or break an organization.
Even a software organization.
There are many ways for software products to survive, and many of them don’t depend on quality:
Some software is built for an internal audience, who are captive customers. They have to accept whatever sh*t we developers deliver to them.
External customers can be so bound to a specific vendor that they may as well be captive. (This can be due to contracts, or because of deep integration with the client’s systems, or sometimes even downright corruption)
The competition may be just as bad, suffering from the same bugginess and slowness problems.
A strong sales and customer care teams can compensate for lack of features.
And many more considerations, completely unrelated to software.
Once I woke up to the truth Cupać’s arguments, I realised that I was the victim of dogmatic thinking.
I was so convinced that “high quality” (whatever that is) is the right thing, that I refused to consider the evidence before me.
Like an Orwellian sheep, I bleated “High quality good! Low quality bad!” without questioning.
That’s not to say that I now think that “High quality good! Low quality better!”.
As many commenters on Cupać’s post observed, while high quality isn’t necessary for success, it improves the chances of it.
Even if bugs and long wait times are acceptable, no bugs and short wait times represent a competitive advantage.
I now arrived at a more refined view of technical quality. Where high quality is nice to have, but is not the be-all-and-end-all.
Organizations can be justified in choosing not to invest in quality. And they’re not “wrong” for doing it.
Up until now, I assumed that every organization should aspire to high quality of software delivery. And if they don’t have that currently – then surely they’re working towards it.
And I’ve been disappointed many times when companies turned out to not share in my dogma.
This new insight will fundamentally change the way I view software organizations.
Especially, it would help me to consider which organizations align well with my preferences on quality (yes, they are preferences, not absolute truths), and which aren’t.
So thank you, Valentina, for your thought-provoking post.
I loved to hate it.
The Useless Dev blog 
I dunno if I agree with your assessment in its entirety. What you say is true – “quality” is not a necessity. But the lack thereof has to be made up somewhere, whether that’s manual interventions, urgent bug fixing, excellent sales and aftercare… Whatever it is, the price is paid somewhere.
You can choose to pay that up front. Lots of testing, fully featured products that don’t break. Or later, through some other means. Each case is going to be individual. Most are going to be best served in the middle somewhere.
LikeLike
“You know what I haven’t seen? not once in 15 years?
A company going under.”
Sure, RIM still *technically* exists but it surrendered one of the largest software markets in the world, and doesn’t really even make software any more. I don’t think this is great support of moving slow and shipping hugs that you think it is.
LikeLike
What’s RIM?
LikeLike
I understand the words. I don’t understand what they (or you) mean.
As I read this, you seem to be saying that your only responsibility is to your employer, and that you have none to your customers. I don’t believe that’s what you mean, but that’s what I got out of this. Could you please elaborate?
LikeLike
You know what, i didn’t think of it that way at all.
But i guess you’re right – i *am* saying that the employee’s responsibility is to the employer, and the responsibility to the customer falls on the employer, not employee.
I think that’s fairly reasonable (outside of obvious exceptions such as ethical issues, fraud etc).
At the end of the day, the customer is in business with my employer, not with me.
LikeLike