It’s funny to realize how this wonderful sentence applies to software engineering and especially when we deal with software quality.
Do right things
What does it mean?
It should be about morality: the good and the bad.
Okay, so what is good software?
If you’re in the software engineering business, the software is good when it’s loved by its users, provides useful functionalities, a fancy user experience, etc.
You may disagree with this, but I think the “right thing” part of the software comes from the outside, from the users.
So if you ask this question: “Is it the right thing to do?” you should think about the users, “Is it the thing they ask to?”
Do things right
Isn’t that the same thing?
Not at all. It isn’t about morality. It’s about how you make the software.
You do things right when you make the software as it should be made. It’s all about quality.
Again, you may disagree with this, but I think the “things right” part of the software comes from the inside. How you develop it, test it, deploy it, maintain it, etc.
So if you ask this question: “Am I doing things right?” you should look inside the software and how you make it.
To do right things or to do things right?
Should we have to decide which side we’re on?
Humm. Not really. To be clear, first, do the right thing. Otherwise, your business won’t last.
And then, you should do things right. Otherwise, there won’t be any quality, and your business will fall eventually.
You may remember this famous movie: the good, the bad, and the ugly. There is a kind of metaphor here. If you’re not doing the good thing, then you’re bad. If you’re doing the good thing, but you don’t do things right, then you’re ugly. So, to be good, you have to do the right thing and do the things right.
Getting started
I think that approaches and tools can be categorized as “right thing” or “things right”.
For example, the approaches that help you to better understand your users’ needs and define the requirement are “right thing” approaches. They help you to do the right thing. We can mention the Behavior-Driven Development and the Event Storming sessions, where stakeholders meet to align their understanding of the business domain.
The Domain-Driven Design (DDD) provides
patterns to ensure your code is the closest to users’ problems, so it’s a bridge between the right thing and things right.
Practices such as
code reviews and
pair/mob programming help your team improve the quality of your software and thus guide you to do the “things right”.
With Packmind, we definitively work on the “things right” side. We provide a tool that helps you define, discuss and apply your expertise and your software development best practices.
These two concepts are fundamental when you’re building software; never forget that!
