CodingPleasure

cultivate passion for everything else that goes on around programming

Tag Archives: code devil refactor kiss unit testing

Choosing not to believe in the devil doesn’t protect you from him

I watched “The Rite” the other day. Unfortunately I was quite tired and fell asleep at about half time. But I remember this quote:

Be careful, choosing not to believe in the devil doesn’t protect you from him.

As in my previous posts, I want to try to identify some correlation between a movie quote and the software development world.

Is there a devil in software development? Is there something we must protect ourselves from when writing code? And if yes, how can we protect ourselves?

When I write code or when I’m reviewing code, I noticed some things that could stand for the “devil of coding”. Some are simpler, some are more complex, but all of them could be considered as pitfalls, which sooner or later will come back and haunt you. Let’s analyze some of them:

  • not using coding guidelines: either you don’t have coding guidelines at all or you are not sticking to them, it’s both as bad. It distracts fellow developers when they’re doing code reviews. A bad impression about the code will make other developers not wanting to even touch the code. It’s scary as hell. You can compare it to a book full of small spelling mistakes. Would you want to read the whole book?
  • not doing code reviews: You have to see and check code written by your team mates. You also have to check your code, too. And this regularly! You have to check your code after some days after you have written it. You will find you could have written it better and will think to yourself: “was I possessed when I wrote it?”. Even if you are not hired to do code reviews (yes, there are actual jobs for code reviewers), you still have to look over every check-in of your team members when it occurs or at least when you have to use something they have developed. Remember: you actually have access to the code written by your colleagues. Use it to learn something from it or tell your opinion to the others if you think the lurking devil may be inside the code you just saw.
  • don’t over complicate things: I mean: just KISS the devil! It’s always a tendency to over complicate things. Probably by making an overcomplicated architecture, by using complex class relationships or by using super long methods with lots of parameters the developers try to impress someone with their advanced coding skills. But its quite the opposite, I would say. Those developers who are able to keep everything simple and understandable are the ones who build maintainable, stable and future oriented solutions. “Simplicity is the ultimate sophistication!
  • not refactoring quick&dirty implementations: It’s always the same: a developer is asked to try something out, or he just wants to show how quick he can implement it, and he goes right ahead and writes the code to do that. What he actually did by following this approach is to develop a prototype. But as everyone knows, prototypes are meant to be a proof-of-concept. Prototypes validate a concept, nothing more. Afterwards, the prototype should be thrown away and based on the facts learned, the actual implementation should be done. This means: rewrite the evil prototype code! Refactor it, document it, test it, connect it to other components in the project. Let it then be reviewed, not before. If you don’t have time to rewrite it, the least you can do is mark the whole code with a TODO statement, so that you remember to do it someday. Thinking “Oh, cool! It worked just straight ahead! I’ll check it in and I’m done.” is like thinking the devil doesn’t exist!
  • not using Unit Testing: I heard a lot of reasoning that unit testing aren’t really useful, that there isn’t enough time to write tests, that eventually you still won’t have 100% code coverage, etc. But this is actually like saying the devil doesn’t exist, when in fact, everyone knows that no code is perfect and the probability that there are bugs in your code is actually so high that all reasoning against unit testing is worthless: you just have to do everything possible to limit the number of bugs found in your code.

The conclusion is: not being aware or ignoring these things won’t help you in your career. Sooner or later, the devil will catch you! You have to protect yourself by learning and reading about these topics. Acknowledge them as part of your life as a software developer. Be vigilant and pragmatic! It’s all up to you to become a better programmer. Don’t rely on exorcists to fight out the devil in your own code.

Advertisements