Different beliefs about software quality

I recently got a great question on Twitter which got me thinking for a while and I decided to share my thoughts about it.

Context

But first, some context: I am feeling great because the codebase where I work is getting better and better, so I am tweeting this:

“As software improves with time, you can feel you’re doing right.”

And then I got a question asking for suggestions:

So there we go…

My answer

Create agreements

The first thing is to create agreements about what quality software means for your team and yourself. This helps clarify what software culture you want to establish and work towards that direction. Leaving your company should be the last resort once you have no other option.

Before thinking about leaving your company, I would ask you:

• Why do you think you cannot improve the working codebase of your company?
• What can you do to reduce the friction between your different beliefs regarding what quality means for software?

There is no perfect codebase to work on because software is a living entity and constantly changes. So, at least for me, quality software is the one that can cope with change smoothly.

Once you have agreed on that goal, and while there are multiple ways to achieve that result, my favorite way of working is keeping an agile mindset with doses of extreme programming values, principles, and practices in mind.

Software is about people

Software is not just about writing clean and solid code. This is indeed desired, and we should aim for that, but we must first understand why we want that. The “why” is based on the values that you have as a team.

If you don’t share the same purpose, the same “why,” then you won’t enjoy working together, and in such a case, I would advise looking for another company that shares your values. But, before that, I would strongly suggest fixing the deeper issue and helping your team improve.

Understanding your why

You first need to deeply understand your “why” so you can transmit this to your peers and the people around you. Have you tried all you can to create awareness about your “why”?

Some ideas include encouraging collaborative programming (pair/mob), presenting some internal tech talks, creating a culture of sharing knowledge on a regular daily basis, creating awareness about the current status quo, and looking for opportunities to improve everywhere.

Your career path

If, after several months of (really) trying these ideas, none of them work, look for a new company that shares your beliefs. After all, you’re the first and primary responsible person for taking care of your career path.

Original twitter thread.

Extra thoughts

If you want something to be different, don’t wait till it’s changed automatically. Try to change it; if it’s not working, leave it. Maybe you don’t belong in that place.

On the other hand, it’s crucial to reflect if you see that pattern often repeating (changing companies too quickly). In such a case, maybe the problem isn’t the companies but yourself.

Software development is not just about code but business. It’s essential to be aware of finding a fair trade-off between speed, costs, and quality, depending on the situation. You might want to use some tech debt to conquer the market as soon as possible.

It doesn’t make sense to have “low quality” as part of the identity of any team. Every team has certain quality expectations. Therefore, the key here is to agree on what good quality is.

Thanks to my former Engineer Manager, Evgenii Sokolov, who inspired me to write these extra lines after sharing the original post.

Related posts

• The art of testing: where design meets quality. From a software developer’s point of view
• Understanding people. Misunderstandings, effective communication, and self-reflection
• Update your team to be more extreme. How can you help your peers to embrace the change?

Recommended readings

• Extreme Programming Explained by Kent Beck
• Peopleware by Tom DeMarco
• Clean Agile by Robert C. Martin