6

Responding to “Are bugs and slow delivery ok?”: The blog post that I’ve hated th...

 1 year ago
source link: https://uselessdevblog.wordpress.com/2023/07/03/responding-to-are-bugs-and-slow-delivery-ok-the-blog-post-that-ive-hated-the-most-ever/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client
Home Menu

Responding to “Are bugs and slow delivery ok?”: The blog post that I’ve hated the most, ever

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.

Advertisement

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.

Loading...

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK