Those of you who’ve already read some of my articles have probably noticed that I’m sort of a developer that is extremely passionate about code that is clean. The reason behind this fanaticism is not my fascination with pure beauty because I’ve never treated code as art as such. I’m so much focused on writing clean code and maintaining code readability because … I’m a really lazy person.
I just think that code that is easy to understand makes my (and not only my) work easier. I don’t have to spend tremendous amount of time going over the code and seeking answers to my questions.
I know that small additional effort during introduction of something new into the code base will save a lot of time in future. Yet, this would impossible if I’m the only person in the project with this great passion to writing self-descriptive code. It has to be team work.
So many of those who know how to do it well
Most of developers I know would agree on what are the good practices regarding software development. Continuous refactoring, well written tests, TDD, code review to name just a few.
During discussions over coffee they talk a lot about benefits that come with following those practices.
Then they’re back to their desks and… somehow they’re not refactoring the code. Why? Because “I was in the zone, man”. They’re not writing tests, because “the deadline is too tight and I was in a rush”.
Maybe you also experienced this. Maybe you shaking your head right now. Yet, it happens. I saw it too many times. Those great developers who are evangelising others, they… well… forget what they’re saying when they’re writing the code? Or maybe they’re just so good those practices are not applicable for them any more?
Don’t do it?
Maybe it would be just as simple as stop keeping repeat that TDD (and refactoring, code review and other practices) is so great because writing a code in this way help us increase quality and readability of the code? Well, I proposed it a few times and I always hit the loud wall of objections.
Well, when you are not doing something stop convincing others to do it. It sounds reasonable, doesn’t it?
No one ever agreed on that though, which is of course good, because my intention when I shared my proposition was to awake developers around me, not to stop following those practices.
That was good, but didn’t solve the problem. So what can help?
Pair programming for the rescue!
I can understand people who prefer to do things in the way that is easier and more familiar for them. In the way they’ve got some experience in. The known is always better than the unknown. The known is easier than the unknown. If people don’t have experience in TDD for an example they would prefer to write code in a different way.
But are they not the same people who extol TDD?
The answer is yes and this is what can serve as an advantage.
Pairing is the practice that may help developers gain some experience. Why can it work?
Where no one is looking, it is easier to make an excuse. To convince yourself that would be better (faster and easier) to make it in old school way, not struggling with this fancy TDD.
I think that most of us tend to choose less effort whenever possible. As I already wrote – the known is simply easier. But is it better?
This happens when we are left alone. It’s pretty easy to write code in this way when we don’t have to explain anyone why we are not following the practices we are so strongly recommending.
It changes when we sit together with another developer. We are no longer so willing to not to adhere to recommended practices. Why? Because we would have to explain ourselves. We have to have an excuse. And not a paltry excuse but a solid one. And it’s hard to make such an excuse. So we are choosing easier way – we are following those practices.
We are improving the code, we are writing it in good way from scratch, we are writing descriptive tests and many more.
It’s so good that we constantly try to minimize the effort needed to accomplish something.
Let’s use it as an advantage!
| Reference: | Pair Programming for the rescue! from our JCG partner Sebastian Malaca at the Let’s talk about Java blog. |
