About me

Should the quality of code be of the goal of a developer? Hmm… In my opinion the question should be stated slightly differently. We should think about it from much wider perspective.
Regardless how harsch it sounds the goal of each programmer any company employs is providing business value to the customers.We can achieve this goal only by providing software that works correctly and solves the customer’s issues. If your company can provide expected functionality and sell the product – then all the software that has been written is useless. Even if it was of very high quality!

Once we know that first of all our product needs to work correctly and bring the business value to our customers then we can ask ourselves slightly different question : Is it possible to provide expected business value based on code of poor quality like unreadable, untestable, badly-designed? Is it possible to do this especially continuously in long term? How likely will we be enhancing and extending our product with new features or changes to the code? What skills do we need to overcome such challenges?
Coming into the above questions about refactoring took me really a lot of time. But now I know that we can find the right answers only if we ask ourselves the right self-learning questions. This is what I do wish you a lot!

Of course, when I started working as a programmer in 2001 I took care of the quality of code as well. But at that time I thought that code quality is the goal itself. I was surprised why the business people were not that enthusiastic about the improvements I’ve been introducing into my code and was proud of… Most likely because the code was still providing the same functionality whereas the clients were waiting for new features…
Focusing on business quality only was working quite well upto certain point of project size. Behind this point our customers were able to find cases where the functionality didn’t work as expected and they were faster than us in doing it… Moreover while we were correcting existing defects we were introducing new ones….
Time was going on. When searching for better code quality I was changing jobs or teams in the companies I was working for. At a certain point just by coincidence I joined a team that was partially doing some programming, some administration but also some technical trainings! We were also allowed to introduce new trainings so I could take part in doing this. This way I could try playing with my own trainings in the company as well.
And at this point my journey with teaching started and I knew it is my way to go.
Later I change my job one more time and became a team leader. I was responsible for building a team from scratch, and moreover we were writing a new product from scratch.
The above experience allowed me to look at the issue of code quality from additional perspective – organizational one. This is because you need to find time for maintaining quality through refactoring – not as something additional that can be omitted by but something that is part of software development process.