Stop writing crap code!
One of the biggest challenges that programmers need to face is code quality. Change crappy code hurt our feelings and we love to hate other people's code. But are we writing good code as well? And our team agrees what is a good quality code?
Sometimes we have divergent opinions about what is a "great code" or "crappy code". How can we align the definition of clean and crappy code?
A technique proposed by Henrik Kniberg consists to ask the team to rate about the code produced, on scale of 1 - 5, where 5 means "great code" and 1 means "totally crappy code".
If we have mostly 4s and 5s, that's a good sign, but if we have a great variation, then we need to explore it. It can mean many things, like different quality in different parts of codes, a gap between technical knowledge from individuals, and many others.
Print the result and put in a place where all members can see. The first step to change is to recognize the problem.
What's the way?
Mostly developers wanna a code that rates 4+, then, we need to define what good quality really means for us and where we want to be as a team. The more divergences you have the hardest it's to improve our code.
What's wrong?
Crappy codes are written by programmers, we are responsible and we must to admit this fact. We must care about the health of the project, the quality of code that we produce, also about tests coverage, design, performance, security and everything else that matters. We are the owner of this code.
But this code isn't mine, it's a legacy code!!!
Ok, so when you get a task to deal with legacy code, you must finish with a code that is better than the one when you have started. Rate the code when you start and after you finish, if you improved the code, great job, that's the way!!! Otherwise, you are producing bad code and it invite more bad codes, as we can learn in the broken windows syndrome, people tend to adapt new code to the quality already there.
Pair programming, code review and dojos are the the most efficient way to level your team's knowledge, share concepts and patterns between members, therefore producing better code.
Pair Programming is very boring, I don't like this practices
if you want a change, be the change!!!
Productivity
The major lame excuse to justify bad code is time. Aways people say:
We don't have time to write clean code
First of all, we need to ask ourself, "Don't I really have time to write good codes?". Some times we have an anxiety to finish a task, by the desire to start another as soon as possible or by a pressure from managers. But do we (programmers and managers) know the impact of bad codes? Do we really want write bad codes? I hope not!
This is well represented by next image
As time goes by, crappy codes may screw up the project, because it gets harder and harder to add new features or change the existing ones, the team’s productivity goes down and more time are spend to fight with bad codes.
Stop writing crap code and be sure to leave the code better than when you started.
It's not interesting for the business to have low quality code. Maybe we have an important goal toachieve in a short deadline and some good practices are left behind along the way, but when accomplished, go back and clean the dirty. Remember, this must be an exception and not a rule.
Start writing clean code today!
