Imagine the following situation:
You are a programmer and you have figured out that the program you have been working on finally works. That is to say, the tests you made are all green, and you think that it functions as it should. Then you look at your source code.
You can clearly see that it isn’t the best code you have ever produced. So you feel that you should improve upon it. There is a lot of pressure being put on the deadline though. So you decide to ask your manager if he agrees with you that improving the quality of the code is a good idea.
You present your case to your manager and ask him to choose what he thinks is important. And then he chooses to not improve upon the code, focusing instead on the deadline.
What just happened? Assuming both you as an engineer and your manager want a product of high quality, something about what quality is or how it’s being dealt with must be unclear between you.
A different point of view
After having been a programmer for many years, and encountering many problems of this kind, I became a manager of programmers.
Sometimes, they would come to me for advice about what to do with their code. It seemed strange to me that they would come to me at all. I had hired all of them for my team because I believed in them. I believed that they could do the job. And that included that they could make the necessary choices to make sure that we met both current and future goals.
It therefore always seemed to me that they came to me because they had an unfounded desire. That they wanted to do something which they knew was wrong but felt like doing anyway. And that that was the reason they were asking my permission. A strange experience.
I typically answered by not giving them a straight answer. Instead, I would tell them that they knew the goals – both long- and short-term – and that I believed that they could make the correct judgement calls to achieve them.
So what then is quality, and how does a clear definition help us?
Having been in both the programmer and manager seat, I started thinking about what quality then is. Convinced that it must be something that unites what everyone wants in a production environment. Since nobody is ever opposed to good quality, it must be something that is recognizable by all parties in the working environment. Be it engineers, managers, business representatives, customers and senior management.
Quality seems to imply something about a product or production process that makes it good. Good in a few different ways. It needs to be fit for the purpose, to delight the customer, and to guarantee both long- and short-term results. What I came up is this:
The quality of anything is the degree to which it has long lasting, highly functional results.
So how does that help us? Well, with regards to our example. If both you and your manager can agree that this is what quality is, then the solution to the problem becomes easy. If we both want quality, and this is what it is, then we need to value the opinion of the person best capable to assess if the code as it is can guarantee long-lasting, highly functional results. The best person to do that is you as a programmer. You are the expert. So don’t bother your manager with the question, just know that you already have the answer.
Want to feel like quality is a thing that we all care about?
I am on a quest to create teams where people feel energized, love the product they work on and go home feeling fulfilled. Want to join me in my quest? Try out Challenge #3 and let me know in the comments what you experienced.